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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionality and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in 3GPP 
TS 32.240 [1], which provides an umbrella for other charging management TSs that specify: 

- the content of the CDRs per domain and subsystem (offline charging), 

- the content of real-time charging messages per domain / subsystem (online charging); 

- the functionality of online and offline charging for those domains and subsystems; 

- the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or charging 
events) 

The complete document structure for these TSs is defined in TS 32.240 [1]. 

The present document specifies the Offline and Online Charging for MultiMedia Telephony (MMTel) service and 
supplementary services, based on the functional description of MMTel in 3GPP TS 22.173 [200]. Charging for the 
following supplementary services is specified: 

Communications Diversion (CDIV) 

Communication Hold (HOLD) 

- CONFerence (CONF) 

Message Waiting Indication (MWI) 

Originating Identity Presentation (OIP) / Originating Identity Restriction (OIR) 

Terminating Identity Presentation (TIP) / Terminating Identity Restriction (TIR) 

- Call Barring (CB) 

- Explicit Call Transfer (ECT) 
Communication Wait (CW) 

Completion of Communications to Busy Subscriber (CCBS) 
Completion of Communications by No Reply (CCNR) 
Malicious Communication Identification (MCID) 
Customized Alerting Tone (CAT) 

- Closed User Group (CUG) 
Personal Network Management (PNM) 
Customized Ringing Signal (CRS) 
Reverse Charging 

Advice of Charge ( AoC) 

Charging of these supplementary services is performed at the respective MMTel AS. The MMTel charging aspects are 
an extension of the basic IMS charging capabilities as specified in the TS 32.260 [20]. 

This charging description includes the offline and online charging architecture and scenarios specific to the MMTel, as 
well as the mapping of the common 3GPP charging architecture specified in TS 32.240 [1] onto the MMTel. It further 
specifies the structure and content of the CDRs for offline charging, and the charging events for online charging. 

The present document is related to other 3GPP charging TSs as follows: 
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The common 3GPP charging architecture is specified in TS 32.240 [1]; 

The common IMS charging principles are specified in the TS 32.260 [20]. 

The parameters, abstract syntax and encoding rules for these CDR types are specified in TS 32.298 [51]. 

A transaction based mechanism for the transfer of CDRs within the network is specified in TS 32.295 [54]. 

The file based mechanism used to transfer the CDRs from the network to the operator's billing domain (e.g. 
the billing system or a mediation device) is specified in TS 32.297 [52]. 

The 3GPP Diameter application that is used for MMTel offline and online charging is specified in 
TS 32.299 [50]. 

All references, abbreviations, definitions, descriptions, principles and requirements, used in the present document, that 
are common across 3GPP TSs, are defined in the 3GPP Vocabulary, TR 21.905 [100]. Those that are common across 
charging management in GSM/UMTS domains or subsystems are provided in the umbrella document TS 32.240 [1]. 
Finally, those items that are specific to the present document are defined exclusively in the present document. 
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3 Definitions and abbreviations 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [100], 3GPP 
TS 32.240 [1]. 

3.2 Abbreviations 

For the purposes of the present document, the abbreviations defined in 3GPP TR 21.905 [100], 3GPP TS 32.240 [1] and 
the following apply: 

3PCC Third Party Call Control 

3PTY Three-Party 

AoC Advice of Charge 

CAT Customized Alerting Tone 

CB Communication session Barring 

CCBS Completion of Communication sessions to Busy Subscriber 

CCNR Completion of Communications on No Reply 

CD Communication Deflection 

CDIV Communication Diversion 

CDIVN CDIV Notification 

CFB Communication Forwarding Busy 

CFU Communication Forwarding Unconditional 

CFNL Communication Forwarding on Not Logged-in 

CFNR Communication Forwarding No Reply 

CFNRc Communication Forwarding on Subscriber Not Reachable 

CFUDB Communication Forwarding User Determined Busy 

CONE CONFerence 

CUG Closed User Group 

CW Communication Waiting 

ECT Explicit Communication Transfer 

FA Flexible Alerting 

HOLD Communication HOLD 

ICB Incoming Communication Barring 

MCID Malicious Communication Identification 

MMTel MultiMedia Telephony 

MWI Message Waiting Indication 

NDUB Network Determined User Busy 

OCB Outgoing Communication Barring 

OIP Originating Identity Presentation 

OIR Originating Identity Restriction 

PNM Personal Network Management 

CRS Customized Ringing Signal 

TIP Terminating Identity Presentation 

TIR Terminating Identity Restriction 

URN Uniform Resource Name 
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Architecture Considerations 



4.1 High level MMTel architecture 

Figure 4.1 depicts the IMS reference architecture, as described in 3GPP TS 23.002 [103], with "colorized " AS as entity 
involved in MMTel service and supplementary services charging described in this specification. 
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Figure 4.1-1 : Entities involved in MMTel service charging in IMS logical architecture 

The AS provides the application level network functionality for MMTel service and supplementary services, whereas 
the overall IMS Network provides the basic IMS capabilities supporting MMTel service. 

4.2 MMTel offline charging architecture 

Figure 4.2 depicts the MMTel offline charging architecture. 
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Figure 4.2-1 : MMTel Offline Charging architecture 

This MMtel Offline Charging architecture is based on the IMS offline charging architecture described in TS 
32.260 [20], with service CTFs supporting MMtel specific service charging, interfacing the CDF through the Rf 
reference point. 

The CTFs considered in the MMTel Offline Charging architecture reside in the Application level network functionality 
providing MMTel service and supplementary services. 

The CTFs related to charging for the IMS basic capabilities supporting MMTel service, are described in TS 32.260 [20], 
and reside in the set of IMS Nodes (S-CSCF, MRFC.) reflected in IMS offline architecture. 



4.3 MMTel online charging architecture 

The architecture for MMTel online charging is described in the following figure. 
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Figure 4.3-1 : MMTel Online Charging architecture 

This MMtel Online Charging architecture is based on the IMS onHne charging architecture described in TS 32.260 [20], 
with service CTFs supporting MMtel specific service charging, interfacing the OCS through the Ro reference point. 

The CTFs considered in the MMTel Online Charging architecture reside in the Application level network functionality 
providing MMTel service and supplementary services. 

The CTFs related to charging for the IMS basic capabilities supporting MMTel service, are described in TS 32.260 [20], 
and reside in the set of IMS Nodes (S-CSCF, MRFC.) reflected in IMS online architecture. 



5 MMTel charging principles and scenarios 

There are a variety of multimedia telephony supplementary services implemented at different IMS nodes. All the 
services should support subscription based charging, and some also consumption based charging. The subscription 
based charging is out of the scope of the present specifications. 

The following table 5.1 summarizes which of the services are applicable for offline and online charging. 
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Table 5.1 : Relevance of the services for offline and online charging 



Supplementary services 


Offline Charging 


Online Charging 


OIP 


X 


- 


OIR 


X 


- 


TIP 


X 


- 


TIR 


X 


- 


CW 


X 


- 


HOLD 


X 


- 


CB 


X 


- 


MWI 


X 


- 


CONF 


X 


X 


CCBS 


X 


- 


CCNR 


X 


- 


CDIV 


X 


X 


CDIVN 


X 


X 


ECT 


X 


X 


FA 


X 


X 


MOID 


X 


- 


CAT 


X 


- 


CUG 


X 


X 


PNM 


X 


- 


CRS 


X 


- 


AoC 


X 


- 



5.1 MMTel charging principles 



The MMTel charging encompasses the Multimedia telephony service (e.g. multimedia conversational communications 
between two or more users, with speech as a typical usage, and also others combinations of media) together with the 
associated supplementary services charging aspects. 

Every Supplementary services described in TS 22.173 [202] are subject to be involved in MMTel charging function 
description. 

MMTel service and supplementary services charging function focuses on charging information provided by the CTFs 
supporting MMtel specific service charging: calling user identification, called user identification, media component 
characteristics and usage (speech only, speech with other component, add/retrieve components..), supplementary 
services applied . . .It enables to apply different flexible charging based on supplementary service type and options. 

All the CTFs supporting MMtel specific service charging (AS) pertain to IMS domain, and as explained in TS 32.260 
[20], it is possible to correlate session/transaction related charging data generated from these different Nodes (AS), and 
others IMS Nodes involved in the session used for MMTel service handling , based on IMS Charging Identifier (ICID). 

For AS(s) providing MMTel specific service and supplementary services, the "OneChargingSession" option, as 
described in TS 32.260 [20] can be applied, when acting as a B2BUA with IMS Charging Identifier (ICID) preserved 
between dialogs. 



5.1.1 



Supplementary services invocation 



5.1.1.1 



OIP charging 



The OIP service provides the terminating user with the possibility of receiving trusted (i.e. network-provided) identity 
information in order to identify the originating user. 

The charging of the OIP subscribers is measured by the MMTel AS handling OIP in offline charging only. 
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5.1.1.2 OIR charging 

The OIR service is a service offered to the originating user. It restricts presentation of the originating user's identity 
information to the terminating user. 

The charging of the OIR subscribers is measured by the MMTel AS handling OIR in offline charging only. 

5.1.1.3 TIP charging 

The Terminating Identification Presentation (TIP) service provides the originating party with the possibility of receiving 
trusted information in order to identify the terminating party. 

The charging of the TIP subscribers is measured by the MMTel AS handling TIP in offline charging only. 

5.1.1.4 TIR charging 

The Terminating Identification Restriction (TIR) is a service offered to the terminating party which enables the 
terminating party to prevent presentation of the terminating identity information to originating party. 

The charging of the TIP subscribers is measured by the MMTel AS handling TIR in offline charging only. 

5.1.1.5 HOLD charging 

The Communication Hold supplementary service enables a user to suspend the media stream(s) of an established IP 
multimedia session, and resume the media stream(s) at a later time. 

The charged parties may be any of the Hold parties. These roles are: 

• Calling Party; 

• Called Party; 



Editor's note: When one of the parties originates a new call to a third party and the new call overbooks the bearer 
resource reserved by the held call, overbooking may be taken into account in charging. The solution for 
that is ffs 

5.1.1.6 CB charging 

The Communication Barring (CB) service offers the following services: 

• The Incoming Communications Barring (ICB) is a service that rejects incoming communications that fulfil 
certain provisioned or configured conditions on behalf of the terminating user. 

• The Anonymous Communication Rejection (ACR) is a particular case of the ICB service, that allows barring 
of incoming communications from an anonymous originator on behalf of the terminating user. 

• The Outgoing Communication Barring (OCB) is a service that rejects outgoing communications that fulfil 
certain provisioned or configured conditions on behalf of the originating user. 

The charging of the CB subscribers is measured by the MMTel AS handling CB in offline charging only. 

5.1.1.7 CDIV charging 

The Communications Diversion (CDIV) services enables the diverting user, to divert the communications addressed to 
the diverting user to another destination. 

There are three actors active in a CDIV service of one diversion with the following roles: 

• Diverting user; the party that initiates the diversion of an incoming communication. 
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• Originating user; the party which has initiated the communication and that stays in the communication which is 
diverted; 

• Diverted to user; 

In case there is another diversion, the user that was first the diverting user (user B), will be the originating user in the 
second diversion. The diverted to user of the first diversion (user C) will be the diverting user of the second diversion. 

The charging of the diverting user for the B-C leg is measured by the MMTel AS handling the CDIV service, i.e. by the 
MMTel AS of the diverting user (user B). For the diverting user a separate charging dialog (online and/or offline 
charging) is needed. Charging of the originating and the terminating user (user C) is done in alignment with the TS 
32.260 [20]. 

Typically the diverting user is charged for the forwarded leg (B-C leg), however, normal roaming charging principles 
apply for the diverted to user also in case of communication diversion. If there is another diversion, the user that 
performs the second diversion (user C) is charged (typically) for the new forwarded leg (C-D leg). 

Charging at the S-CSCF is done in alignment with the TS 32.260 [20] but the S-CSCF has no knowledge of the CDIV 
service. 

5.1.1.8 CW charging 

The CW (Communication Waiting) service enables the application server to indicate to the subscriber, that there is at 
least one new communication is requested, and that no resources are available for that incoming communication. The 
user has then the choice of accepting, rejecting or ignoring the incoming communication. The maximum number of 
communications that may be waiting is a service provider option. If the current number of communications waiting is 
equal to the maximum, then any new attempted incoming communication request shall be rejected with a busy cause. 

The charging of the CW subscribers is measured by the MMTel AS handling CW in offline charging only. 

5.1.1.9 ECT charging 

The Explicit Communication Transfer (ECT) service provides a party involved in a communication to transfer that 
communication to a third party. 

There are three actors active in a transfer, they are acting in the following roles: 

• transferor: the party that initiates the transfer of the active communication that it has with the transferee; 

• transferee: the party which stays in the communication which is transferred; 

• transfer target: the party which the communication is transferred to and which replaces the transferor in the 
communication. 

The charging of the Transferor is measured by the MMTel AS handling the ECT service for the Transferor. The 
charging of the Transferee is measured by the MMTel AS handling the ECT service for the Transferee. 

5.1.1.10 IVIWI charging 

The MWI service enables the application server to indicate to the subscriber, that there is at least one message waiting. 
The indication is delivered to the subscriber's UE after successful subscription to the Message Waiting Indication 
service as described in the present document. 

The charging of the MWI subscribers is measured by the MMTel AS handling MWI in offline charging only. 

5.1.1.11 CONF charging 

The CONFerence (CONF) service enables a user to participate in and control a simultaneous communication involving 
a number of users. 

CONF Charging for the conference owner could be based on: 

• establishment of the conference 
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• number of participants 

• duration 

CONF Charging for the conference participants could be based on: 

• duration 

The charging of the conference owners and participants is measured by the SIP AS and MRFC handhng conference 
service. For each participant (call leg) a separate charging dialog (online and/or offline charging) at the SIP AS is 
needed. 

5.1.1.12 CCBS charging 

The CCBS (Completion of Communication to Busy Subscriber) service enables user A, encountering a busy destination 
B, to have the communication completed without the user having to manually initiate a new communication attempt 
when the destination B becomes not busy. 

When user A requests the CCBS supplementary service, the network will monitor for destination B becoming free 
again. 

When destination B becomes free again, the network will wait a short time in order to allow the resources to be re-used 
for originating a communication. If the resources are not re-used by destination B within this time, the network will 
automatically recall user A. 

When user A accepts the CCBS recall, the network will automatically generate a CCBS call to destination B. 

The charging of the CCBS suscribers is measured by the MMTel AS handling CCBS in offline charging only. 

5.1.1.13 CCNR charging 

The CCNR (Completion of Communications on No Reply) service enables user A, encountering a destination B which 
does not answer the communication (No Reply), to have the communication completed without the user having to 
manually initiate a new communication attempt when the destination becomes not busy after having initiated and 
completed a new communication. 

When user A encounters a destination B which does not answer the communication (No Reply), user A can request the 
CCNR supplementary service. 

When user A requests the CCNR supplementary service, the network will monitor for destination B becoming not busy 
after having initiated and completed a new communication. 

When destination B becomes not busy after having initiated and completed a new communication, the network will wait 
a short time (as defined by the destination B idle guard timer) in order to allow the resources to be reused for originating 
a communication. If the resources are not reused by destination B within this time, the network will automatically recall 
user A. 

When user A accepts the CCNR recall, then the network will automatically generate a CCNR call to destination B. 

The charging of the CCNR suscribers is measured by the MMTel AS handling CCNR in offline charging only. 

5.1 .1 .14 Flexible Alerting charging 

Flexible Alerting (FA) causes a call to a "Pilot Identity" to branch the call into several legs to alert several termination 
addresses (FA group members) simultaneously. Additional calls may be delivered to the FA Pilot Identity at any time. 
The first leg to be answered is connected to the calling party. The other call legs are abandoned. 

The FA group, identified by the "Pilot Identity" consists of a list of FA group members alerted through their the public 
addressable identity. 

The charging of the "Pilot Identity" is measured by the MMTel AS handling Flexible Alerting for the "Pilot Identity". 
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5.1.1.15 MCID charging 

The MCID service enables an incoming communication to be identified as malicious and registered. 

The Network shall register the communication related information (such as Terminating Identity Information, 
Originator Identity Information, Local Time and Date...), which shall be kept under Network Operator's control (i.e not 
available to the terminating entity nor the originating entity). 

This service has two modes: permanent mode and temporary mode. The permanent mode is active for all incoming 
communications, and the temporary mode is active only for the incoming communications declared by the served user. 

The MCID service can be invoked during the active phase of the communication, or after the active phase for a limited 
period (but never after communication termination) by the served user, or, automatically invoked during the alerting 
phase. 

The charging of the MCID subscriber is measured by the MMTel AS handling MCID service for the called subscriber 
in offline charging only. 

5.1.1.16 CAT charging 

The Customized Alerting Tone Service (CAT service) is an operator specific service by which an operator enables the 
subscriber to customize the alerting tone which is played to the calling party. 

The charging of the CAT subscriber is measured by the MMTel AS handling CAT service for the called subscriber, in 
offline charging only. 

5.1.1.17 CUG charging 

The CUG service enables users to form groups of members, whose communication profile is restricted for incoming 
and outgoing communications. Members of a specific CUG can communicate among themselves but not, in general, 
with users outside the group. 

Specific CUG members can have additional capabilities that allow them to initiate outgoing communications to users 
outside the group, and/or to accept incoming communications from users outside the group. Specific CUG members can 
have additional restrictions that prevent outgoing communications to other members of the CUG, or prevent incoming 
communications from other members of the CUG. 

A specific user may be a member of one or more CUGs. 

The charging of the CUG subscribers is measured by the MMTel AS handling CUG service for offline and online 
charging. 

5.1 .1 .1 8 Personal Network Management Charging 

The Personal Network Management (PNM) service allows a user to manage his UEs in regard to terminating services 
according to preferences set by the user, capabilities and availabilities of devices. Charging for the "FN UE redirection" 
functionality of the defined PNM service, is considered in the scope of MMTel supplementary service charging, and 
applies to the active UE the terminating services are delivered to. 

The charging of the PNM subscribers is measured by the MMTel AS handling PNM in offline charging only. 

5.1 .1 .1 9 Customized Ringing Signal Charging 

The Customized Ringing Signal (CRS service) is an operator specific service by which an operator enables the 
subscriber to customize the ringing signal which is played to the called party. 

The charging of the CRS subscriber is measured by the MMTel AS handling CRS service for the called or the calling 
subscriber, in offline charging only. 
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5. 1 . 1 .20 Reverse Charging 

The Reverse Charging at communication set up time service allows the terminating party to be charged for the entire 
communication. The service, requested by the originating party at communication set up time, is explicitly indicated to 
the terminating party so he can accept or deny the reverse charge communication request. 

Editor's Note: no stage 3 description for Reverse Charging in this Release: ffs 

5.1.1.21 AoC charging 

The AoC service allows the served user to be provided with MMTel service charging information related to: 

• AoC at communication set-up time (AoC-S) 

• AoC during the communication (AoC-D) 

• AoC at the end of the communication ( AoC-E) 

The AoC related charging information provided by the MMTel AS is applicable in offline charging only. 

5.1 .2 Supplementary services management by User 

When an IMS supplementary service control can be provided to the UE as a subscription option, every action performed 
by the user for this service (Provision/Withdrawal, Registration/Erasure, Activation/Deactivation, interrogation) may be 
subject to produce charging information, but this aspect is out of the scope of the present specification. 

5.2 MMTel offline charging scenarios 
5.2.1 Basic principles 

The MMTel offline charging functionality is based on the CTFs reporting accounting information, by sending Diameter 
Accounting Requests (ACR) [Start, Interim, Stop and Event] to the CDF. 

The circumstances on which the Diameter client uses ACR Start, Interim and Stop, or Events depend on the 
supplementary service type and is determined for each of them. Further details are specified in clause 5.2.2. 

These Diameter Accounting Request triggers may be configured in such a way several MMTel supplementary services 
can be regrouped. Providing this flexibility will allow to improve situations where several MMTel supplementary 
services are handled within the same AS for complying with interactions requirements associated to these MMTel 
supplementary services. 



5.2.2 Diameter message flows 

The flows described in the present document specify the charging communications between the different CTF entities 
and the charging functions for different charging scenarios. The SIP messages and Diameter transactions associated 
with these charging scenarios are shown primarily for general information and to illustrate the charging triggers. They 
are not intended to be exhaustive of all the SIP message flows discussed in TS 24.228 [200] and they depend on the 
Diameter Accounting Requests triggers configured by the operator. 

Although each MMTel supplementary service is described by separated flows illustrating the dedicated trigger(s) for 
this MMTel supplementary service, the Diameter Accounting Request triggers (as stated in 5.2.1), may be configured 
with several MMtel supplementary services information. 

5.2.2.1 Message Flows - Successful Cases and Scenarios 

Following message flows are defined in TS 32.260 [20], and can be re-used for charging the basic multimedia 
telephony capabilities: 
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• Session Establishment - IMS Origination 

• Session Establishment - IMS Termination 

• Mid-Session Procedures 

• Session Release - Mobile Initiated 



5.2.2.1.1 



OIP Originating Identification Presentation 



Figure 5.2.2.1.1-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the OIP service, and CDF after service execution. 



Originating UE-A Home Network 



UE-A 



S-CSCF A 



1. INVITE 



3. 200 OK 



6. ACK 



1. INVITE 



3. 200 OK 



6. ACK 



Terminating UE-B Home Network 



S-CSCF B 



AS-B 



1. INVITE 



CDF 



UE-B is Subscribed to OIP 



2. INVITE 



3. 200 OK 



3. 200 OK 



6. ACK 



6. ACK 



2. INVITE 



3. 200 OK 



4. ACR [Start/Evt nt] 



UE-B 



UE-A is 
calling 



Open/Create an AS CDR 
Indicate OIP on the AS 
CDR 



5. ACA 



6. ACK 



Figure 5.2.2.1.1-1: Message Sequence Chart for Offline charging of OIP service. 
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5.2.2.1.2 



Originating Identification Restriction (OIR) 



Figure 5.2.2.1.2-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the OIR service, and CDF after service execution. 



Originating UE-A Home Network 



Terminating UE-B Home Network 



UE-A 



S-CSCF 



AS 



CDF 



x-CSCF/AS 



1. INVITE 



IFC for A 



3. 200 OK 



6. ACK 



1. INVITB (Privacy: ID) 



If UE-A is 
Subscribed to OIR 
"Privacy: ID" info is 
added if not existing 
already 



^VITE (Privacv: 



ID) 



3. 200 OK 



3. 200 OK 



6. ACK 



6. ACK 



2. INVITE 



4. ACR [Start/Event] 



Privacy: ID) 



3. 200 OK 



Open/Create an AS CDR 
Indicate OIR on the AS 
CDR 



5. ACA 



6. ACK 



UE-B 



2. INVllTE (Privacy: Ip) 

► 



"Presentity 
withheld" 



3. 200 OK 



6. ACK 
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5.2.2.1.3 



Figure 5.2.2.1.2-1 : Message Sequence Chart for Offline charging of OIR service. 



Terminating Identification Presentation (TIP) 



Figure 5.2.2.1.3-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the TIP service, and CDF after service execution. 



Originating UE-A Home Network 



Terminating UE-B Home Network 




AS 



CDF 



Session Initiation 



1.2000s; (Privacy: none) 



^ .200 OK (Privac 



4. ACK 



1.200 OK (Privac: : none) 



UE-A is subscribed to 
the TIP service. 



none) 



4. ACK 



4. ACK 



2. ACR [Start/Event] 

► 




1.200 OK (Privacy: none) 



Open/Create an AS CDR 
Indicate TIP on the AS 
CDR 



3. ACA 



4. ACK 



OK (Privacy: lone) 



4. ACK 



5.2.2.1.4 



Figure 5.2.2.1.3-1 : IVIessage Sequence Chart for Offline charging of TIP service. 



Terminating Identification Restriction (TIR) 



Figure 5.2.2.1.4-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the TIR service, and CDF after service execution. 
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Originating UE-A Home Network 



Terminating UE-B Home Network 



UE-A 



X-CSCF/AS 




1. 200 OK rPrivack 

< 



"Connected witli 
unknown" 



4. ACK 



x-CSCF B 



AS-B 



CDF 



Session initiation 



1.2 
1.200OKfPrivacv:ID) 



ID) 



4. ACK 



1. 200 OK 



1.200 OK tPrivacv: 



Privacv: ID) 



ID) 



UE-B is subscribed to 
the TIR service and 
can add the Privacy: 
ID header and value if 
they are missing. 



)0 OK (Privacv: ID) 

-* 



4. ACK 



4. ACK 



2. ACR [Start/Event] 

► 



UE-B 




Open/Create an AS CDR 
Indicate TIR service on AS 
CDR 



3. ACA 



4. ACK 



Figure 5.2.2.1.4-1 : Message Sequence Chart for Offline charging of TIR service. 



5.2.2.1.5 



Communication Hold (HOLD) 



Figure 5.2.2.1.5-1 shows the Diameter transactions that are required between AS which implements the HOLD service, 
and CDF after service execution. The involvement of the AS is optional as it is involved to the HOLD service provision 
only for announcement purposes. 
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Originating UE-A Home Network 



Terminating UE-B Home Network 



UE-A 



S-CSCF 



AS 



CDF 




Ongoing Session 



UE-A initiates 
session on hold 



1. UPDATE 
sip:[5555::5:6 
SIP/2.0... (SDFI ) 



2.200 OK 



5. ACK 



:1006;comp=sig 
a=sendonly / a= 



comp 
nactive 



1. UPDATE... 
< ► 



2.200 OK 



2.200 OK 



5. ACK 
< ► 



3. ACR [Start/I iterim/E vent] 




1. UPDATE. 



2.200 OK 



Open/Update/Create the AS CDR 
Indicate HOLD on the AS CDR 



4. ACA 



5. ACK 



1 .UPDATE. I 



"HOLD" 



2.200 OK 



5. ACK 



Figure 5.2.2.1.5-1 : Message Sequence Chart for Offline charging of HOLD service. 

Note: Based on TS 24.610 a scenarion triggerted by Re-Invite is also possible. 

5.2.2.1 .6 Communication Barring - CB (ICB/ACB) 

5.2.2.1 .6.1 Communication Barring (CB) - ICB and ACR 



Figure 5.2.2.1.6.1-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the CB service, and CDF after service execution. 
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Originating UE-A Home Network 



Terminating UE-B Home Network 



UE-A 



X-CSCF/AS 



x-CSCF B 



AS-B 



CDF 



UE-B 



1. INVITE 



4.603 



(Decline) / 433 ( Anonymity Disallowed) 



1. INVITE 



4. 603 (Decline) / 433 



4. 603 (Decline) / 4|33 ( Anonymity Disallowed) 

•^ 



1. INVITE 



UE-B has matching 
ICB/ACR activated 



( Anonymity Disallo\j'ed) 

< 



2. ACR [Event] 



Create an AS CDR 
Indicate ICB/ACR on the 
AS CDR 



3. ACA 



Figure 5.2.2.1.6.1-1 : Message Sequence Chart for Offline charging of CB service. 



5.2.2.1.6.2 



Communication Barring (CB) - OCB 



Figure 5.2.2.1.6.2-1 shows the Diameter transactions that are required between Application Server and CDF, which 
implements the CB service, and CDF after service execution. 
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Originating UE-A Home Network 



UE-A 



X-CSCF 



AS 



CDF 



UE-B 



1. INVITE 



4, 



4. 603 (Decline) 



IJNVITE 



UE-A lias 
matching OCB 

nrtivatpfl 



603 (Decline) 

■4 



2. ACR [Event] 



Create an AS CDR 
Indicate OCB on tiie AS 
CDR 



3. ACA 



Figure 5.2.2.1.6.2-1 : Message Sequence Chart for Offline charging of CB service. 



5.2.2.1.7 



Communications Diversion (CDIV) 



5.2.2.1.7.1 



Communications Diversion (CDIV) - successful establishment 



The following figure shows the Diameter transactions that are required between Application Server,implementing the 
CDIV service and CDF for a successful communication forwarding on no reply. 
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Home Network 



S-CSCF 



1. INVITE 



AS 



iFC for User B 



2. 180 Ringing 



I. INVITE 



1. INVITE 



2. 180 Ringing 



2. 180 Ringing 



CDF 



1 . INVITE 



2. 180 Ringing 



3. Start Timer 



5. Cancel 



4. Timer Expired 



5. Cancel 



6 . SIP signalling :, CFNR logic, release call to user B and Invite towards user C 



8.200 OK 



7. INVITE (user C) 



8.200 OK 



8.200 OK 



7. INVITE (user C) 



8.200 OK 



9. Accounting Request [Start/E\ 



Open/Create an AS 



10. Accounting Answer 



More SIP signalling 



Figure 5.2.2.1.7.1-1 : Message Sequence Chart for Offline charging of CDIV service - establishment 

A communication is requested towards User B, user B has activated the CFNR 

1) INVITE request incoming for User B. Based on the Initial Filter Criteria (IFC) Rules, indicating that User B is 

subscribed to the CDIV supplementary services, the communication is forwarded to an AS implementing AS 
implementing CDIV. Then INVITE is forwarded to User B. 

2) 180 ringing is sent back from User B. 

3) The non-reply timer in the AS is started . 
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4) The timer expires. 

5 to 7) The AS implementing the CDIV service performs the Call Forwarding No Reply logic : release the 
communication to User B, and forward the call towards user C (INVITE request including URI-C as 
destination). 

Depending on the value of subscription option "Originating user receives notification that his communication 
has been diverted (forwarded or deflected)", a 181 (Call Is Being Forwarded) response is sent towards the User 
A indicating that the communication is diverted (not shown in the call flow). 

8) The destination User C party answers and a final response is received. 

9) Upon reception of the final response, the AS implementing the CDIV service sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD/EVENT_RECORD to record call forwarding execution 
(start of the forwarded leg from User B to User C): basic communication information are transferred with 
specific call forwarding information ( service mode= "CFNR", associated number = " user B" as the user who 
invoked the call forwarding). 

10) The CDF acknowledges the reception of the data and opens/creates an AS CDR to record the forwarded leg from 
User B to User C. 

NOTE : Although only the "call forwarding on no reply" case is depicted here , it serves as a basis for all other call 
forwarding modes description (Call Forwarding Unconditional, Call Deflection, Call Forwarding on 
Busy, Call Forwarding Not Logged-in ) for ACR generation : In all these cases, the AS AS implementing 
the CDIV service sends an Accounting-Request with Accounting-Record-Type indicating 
START_RECORD to record call forwarding execution (whatever the mode), when the final response is 
received from user-C. 



5.2.2.1.7.2 



Communications Diversion (CDIV) - release 



The next figure shows the Diameter transactions occurring on release of the previous established communication, 
initiated by user C: 



Home Network 





l.BYE 






















S-CSCF 


AS 




CDF 


1 












l.BYE (User C) 












l.BYE 




2. Accounting Request [Stop] 








l.BYE 










200 OK 










' 










Close the AS CDR 






3. Accounting A 


nswer 






^ 


200 OK 






200OK 


















200 OK 



































Figure 5.2.2.1.7.2-1 : Message Sequence Chart for Offline charging of CDIV service -release 
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1) User C initiates release of the communication 

2) At session termination the AS implementing the CDIV service, sends an Accounting-Request with Accounting- 

Record-Type indicating STOP_RECORD to record stop the call for which User B has been forwarded. The AS 
CDR is closed. 



5.2.2.1.8 Communication Waiting (CW) Charging 

The following figure shows the Diameter transactions that are required between Application Server, which implements 
the CW service and CDF for the callee (subscriber of CW). 
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Figure 5.2.2.1.8-1 : Message Sequence Chart for Offline charging of CW service 

1-2). The communication is initiated by UE-A by sending an INVITE request. The Request URI will include the 
URI of UE-B. After IFC evaluation in the S-CSCF the INVITE request is routed to the CW AS. 

2a). The AS detects the CW condition and inserts a CW indication into the INVITE request per procedures. 

3-4). The INVITE is routed to UE-B. 

5). UE-B recognizes the CW indication per procedures. 

6). UE-B sends back a 180 (Ringing) response. 

6a). out of scope: user B uses the HOLD service or releases a session in order to free resources] 
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7-8). The 180 (Ringing) response is routed back to the AS. 

8a). The AS optionally inserts a Alert-Info with a 'CW URN into the 180 (Ringing) response. 

9-10). The 180 (Ringing) response is routed back to the communication origin. 

9a). The AS may initiate an announcement to the calling user that the communication is a waiting communication, 
in accordance with 3GPP TS 24.628 [4].] 

1 1-14). UE-B sends back a 200 (OK) response to the CW AS and CW AS sends it to the S-CSCF. 

15-17). The CW AS sends an Accounting-Request[Start]/Accounting-Request[Event] to CDF, then the CDF 
opens/creates an AS CDR for the Communication Waiting with CW indication on the AS CDR and returns 
Accounting Answer to the CW AS. 

18). S-CSCF sends back a 200(OK) response to UE-A. 

5.2.2.1 .9 Explicit Communication Transfer (ECT) 

5.2.2.1 .9.1 Explicit Communication Transfer (ECT) : Blind Transfer 

The following figure shows the Diameter transactions that are required between Application Servers implementing the 
ECT service for the transferor and for the transferee, and CDF: a successful Blind Transfert from User A to User C, 
initiated by User B 

For diagram simplification, only one CDF is shown. 
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Figure 5.2.2.1.9.1-1 : Message Sequence Chart for Offline charging of ECT service - Blind Transfer 

(parti) 
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Figure 5.2.2.1.9.1-2 : Message Sequence Chart for Offline charging of ECT service - Blind Transfert 

(part 2) 

In this scenario User A is the transferee, User B is the transferor, and User C is the transfer target. 

User A and User B are in an established communication for which, based on the Initial Filter Criteria (IFC) Rules 
indicating that User B is subscribed to the ECT supplementary service, the INVITE was forwarded to an AS 
implementing ECT (for User A and User B). 

User B puts User A on Hold 

1) User B sends REFER request in the existing A-B dialog, to initiate transfer User A to User C. 

2) this subsequent request is forwarded to the AS implementing ECT. 

3) AS generates an "ECT Session Identifier" replacing User C as the new destination information, for remaining in 

the loop, for transferor's role. 

4) On REFER receipt, this request is forwarded the AS implementing ECT. 

5) The REFER is accepted by User A, and 202 Accepted is transferred from User A to User B. 

6-9) User B sends BYE for terminating original INVITE with User A, acknowledged by 200 OK from User A. AS B 
releases the media between User A and User B which are on hold, then sends an Accounting-Request with 
Accounting-Record-Type indicating STOP_RECORD to record termination of the dialogue between User A and 
UserB. 

10) More signalling between (User A,x-CSCF,AS-A ) and (x-CSCF,AS-B,User B) : 
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User A sends NOTIFY(100 Trying) associated to the received REFER, and User B acknowledges by 200 OK 

1 1) User A initiates a new session by sending an INVITE request with " ECT Session Identifier" . 

12) AS implementing the ECT service correlates this INVITE to the initial session to be transferred and replaces 
"ECT Session Identifier" with User C for creating an INVITE towards UE-C. 

13) The destination User C party answers and a final response is received. 

14) Upon reception of the final response, the AS implementing the ECT service for the transferor, sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD/EVENT_RECORD to record 
Transfer execution. 

15) The CDF acknowledges the reception of the data and opens/creates an AS CDR. 

16) Upon reception of the final response, the AS implementing the ECT service for the transferee, sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD/EVENT_RECORD to record 
User A is transferred, with specific indicator on the transferee's "subscriber role" (whether the transferee was 
engaged in an originating call or in a terminating call) before the transfer execution. 

17) The CDF acknowledges the reception of the data and opens/creates an AS CDR. 

NOTE : The "Consultative Transfer" scenario mainly differs from the "Blind transfer" on the transfer establishment 
phase : when User B has put User A on Hold, User B establishes a communication towards User C and 
puts User C on Hold, then User B initiates the REFER for the transfer triggering. The Accounting- 
Record-Type indicating START_RECORD for recording Transfer execution occurs at the same steps for 
both scenario: on the final response associated to INVITE towards User C for the transferor and for the 
transferee. 



5.2.2.1 .9.2 Explicit Communication Transfer (ECT)) : Release 

The following figure shows the Diameter transactions that are required between Application Servers implementing the 
ECT service for the transferor and for the transferee, and CDF: release from User A, after a successful Blind Transfer 
from User A to User C, initiated by User B. 
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S-CSCF B AS B 



CDF 



l.BYE 



l.BYE 



l.BYE 



l.BYE 



2. Accounting Request [Stop] 



3. Accounting Answer 



l.BYE 



l.BYE 



Close AS CDR 



4. Accounting Request 



[Stop] 
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Figure 5.2.2.1.9.2-1 : Message Sequence Chart for Offline charging of ECT service - Release 

1) User A initiates release of the communication 

2-3) At session termination the AS implementing the ECT service for the transferee, sends an Accounting-Request 
with Accounting-Record-Type indicating STOP_RECORD to record stop the call for which User A has been 
transferred. 

4-5) At session termination the AS implementing the ECT service for the transferor, sends an Accounting-Request 
with Accounting-Record-Type indicating STOP_RECORD to record stop the call transferred by User B. The 
AS CDR is closed. 



5.2.2.1.10 



Message Waiting Indication Charging (MWI) 



The following figure shows the Diameter transactions that are required between Application Server (MWI), which 
implements the MWI service and CDF. 
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Figure 5.2.2.1.10-1 : Message Sequence Chart for Offline charging of MWI service 

1-6) UE subscribes to AS (MWI) and the AS (MWI) returns 200 OK. 

7-10) The AS (MWI) sends NOTIFY request to S-CSCF and the subscriber UE acknowledges the NOTIFY request. 

11-13) The AS (MWI) sends Accounting Request [Event] message to CDF, CDF creates an AS CDR and returns 
Accounting Answer to the AS (MWI). 



5.2.2.1.11 



CONF Charging 



During a conference, user could create the conference, join the conference, invite another user to the conference and 
leave the conference, according to 3GPP TS24.605. The following subclauses respectively show the Diameter 
transactions that are required between Application Server, which implements the CONF service and CDF corresponding 
different conference scenarios. 
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5.2.2.1.11.1 



CONF Charging - user creating a conference 
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Figure 5.2.2.1.11.1-1 : Message Sequence Chart for Offline charging of CONF service- User creating a 

conference 



1-2). The communication is initiated by UE#1 by sending an INVITE request to S-CSCF. And S-CSCF sends back 100 
Trying reponse to inform UE#1 to wait for a while because the request is being treated. 

3-4). S-CSCF transfers INVITE request from UE#1 to CONF AS and the CONF AS sends back 100 Trying response to 
inform S-CSCF to wait for a while because the request is being treated. 

5). The CONF AS allocates the conference URI. 

6-16). After the media resource negociation process, the CONF AS sends back 200 ok response. 

17-19). The CONF AS sends Accounting Request[Start]/Accounting Request[Event] to CDF, then the CDF 
opens/creates an AS CDR for the conference with CONF indication on the AS CDR and renturns Accounting Answer 
to the CONF AS. 
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5.2.2.1.11.2 



CONF Charging - user joining a conference 



The following figure shows the Diameter transactions that are required between Application Server, which implements 
the CONF service and CDF corresponding to the conference scenario: user joining a conference. 
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Figure: 5.2.2.1 .1 1 .2-1 CONF Charging - user joining a conference 

1-2). The conference has already been created. UE#1 sends an INVITE request to S-CSCF in order to join in the 
conference. And S-CSCF sends back SIP 100 Trying reponse to inform UE#1 to wait for a while because the request is 
being treated. 

3-4). S-CSCF transfers INVITE request from UE#1 to CONF AS and the CONF AS sends back SIP 100 Trying 
response to inform S-CSCF to wait for a while because the request is being treated. 

5-15). After the media resource negociation process, the CONF AS sends back SIP 200 ok response. 

16-18). The CONF AS sends Accounting Request[Interim/Event] to CDF, CDF updates or creates an AS CDR for the 
conference and renturns Accounting Answer to the CONF AS. 
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5.2.2.1.11.3 



CONF Charging - user inviting anotiner user to a conference 



The following figure shows the Diameter transactions that are required between Application Server, which implements 
the CONF service and CDF corresponding to the conference scenario: user being invited into a conference. 
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Figure: 5.2.2.1.11.3-1 CONF Charging - user inviting anothier user to a conference 

1-2). The conference has already been created. UE#1 sends a REFER request to S-CSCF in order to invite UE#2 into 
the conference. 

3-4). The CONF AS sends back 202 Accepted response to UE#1 via some related NEs like S-CSCF to indicate that he 
has received the REFER request successfully. 

5-6). The CONF AS sends a NOTIFY request corresponding the REFER request to UE#1. 

7-8). UE#1 sends back SIP 200 ok reponse to the CONF AS. 

9-10). The CONF AS sends an INVITE request to UE#2 in order to invite him into the conference. And UE#2 sends 
back SIP 200 ok response to the CONF AS. 

11-13) The CONF AS sends Accounting Request [Interim/Event] to CDF, CDF updates or creates an AS CDR for the 
conference and renturns Accounting Answer to the CONF AS. 



5.2.2.1.11.4 



CONF Cinarging - user leaving a conference 



The following figure shows the Diameter transactions that are required between Application Server, which implements 
the CONF service and CDF corresponding to the conference scenario: user leaving a conference. 
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Figure: 5.2.2.1.11.4-1 CONF Charging - user leaving a conference 

1-2). The conference has already been created. UE#1 sends a BYE request to the CONF AS in order to quit the 
conference. 

3-5). The CONF AS sends Accounting Request[Interim/Event] to CDF, CDF updates or creates an AS CDR for the 
conference and renturns Accounting Answer to the CONF AS. Conference termination should refer to the description of 
subclause 5.3.2.7 in TS 24.147, e.g. If there isn't any conference policy and the last online conference user quits the 
conference could be considered as the conference termination, when the last online conference user quits the conference 
(sends a BYE request to the CONF AS), the CONF AS sends Accounting Request [Stop/Event] to CDF, CDF stops or 
creates an AS CDR for the conference and returns Accounting Answer to the CONF AS. 

6-7). The CONF AS sends back SIP 200 ok response to UE#I. 

8-10). The CONF AS sends a NOTIFY request to other conference participants that UE#1 has quitted the conference. 

11-12). Other conference participants sends back SIP 200 ok response to the CONF AS. 



5.2.2.1.11.5 



Three-Party (3PTY) Charging - successful establishment 



The following figure shows the Diameter transactions that are required between Application Server, which implements 
the 3PTY service and CDF coiTesponding to the 3PTY scenario: 3PTY service successful establishment. 
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Figure 5.2.2.1 .1 1 .5-1 : Three-Party (3PTY) Charging - successful establishment 
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1) UE-A and UE-B has established communication. UE-A puts UE-B on hold before invoking the 3-Way Calling with 
UE-C. 

2-4) UE-A establishes a call with UE-C following normal call setup procedure and gets UE-C's permission to start the 
3-Way CaUing. 

5) UE-A sends an INVITE request to the 3PTY AS to establish a 3PTY session. 

6-7) The 3PTY AS sends a 200 OK response and receives an ACK request from UE-A. 

8-9) UE-A sends a REFER request to UE-B with the Refer-To header set to the address of the 3PTY AS; UE-B accepts 
the REFER request. 

10-11) UE-B sends a NOTIFY request to UE-A to indicate that UE-B is acting on the REFER request. 

12) UE-B sends an INVITE request to the 3PTY AS to join the 3PTY session. 

13-14) The 3PTY AS sends a 200 OK response to UE-B and receives an ACK request. 

15-16) UE-B sends a NOTIFY request to UE-A to indicate that it has finished action required by the REFER request. 

17-18) UE-A sends a BYE request to terminate the call between UE-A and UE-B. 

19-20) Repeats step 8 to 18 on UE-Aand UE-C to terminate the call between UE-A and UE-C. 

21-23) 3PTY AS sends an Accounting Request [Start/Interim/Event] to CDF, CDF opens or updates or create an 3PTY 
AS CDR for the 3PTY service and returns Accounting Answer to the 3PTY AS. 



5.2.2.1.11.6 



Three-Party (3PTY) Charging - release 



The following figure shows the Diameter transactions that are required between Application Server, which implements 
the 3PTY service and CDF corresponding to the 3PTY scenario: release the 3PTY service. 
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Figure 5.2.2.1 .1 1 .6-1 : Three-Party (3PTY) Charging - release 

1) The 3PTY has already been established. UE-A sends a BYE request to the 3PTY AS in order to release from the 
3PTY service. 
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2-4) At session termination 3PTY AS, sends an Accounting-Request [Stop/Event] to CDF, CDF stops or creates an AS 
CDR for the 3PTY service and returns Accounting Answer to the 3PTY AS. 

5) The 3PTY AS sends back SIP 200 OK response to UE-A. 

6) The 3PTY AS sends a NOTIFY request to other participants that 3PTY service has released. 



5.2.2.1.12 CCBS Charging 

The following figure shows the Diameter transactions that are required between Application Server and CDF, which 
implements the CCBS service, and CDF after service execution. 
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busy state supervisior 
begins 



user B becomes 
available 



30. INVITE sipUE- 



Figure 5.2.2.1.12-1 : Message Sequence Chart for Offline charging of CCBS service 

1-5). The communication is initiated by UE-A by sending an INVITE request. 
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6). UE-B answers with a 486 (Busy Here) response. The 486 (Busy Here) response is routed back to the terminating 
AS. 

7-8). The terminating AS inserts a Call-Info header field in the 486 (Busy Here) response. The Call-Info header field 
will contain the URI of the terminating AS with an "m" header field parameter set to "BS" (busy subscriber). It further 
includes a "purpose" header field parameters set to "call-completion". The 486 (Busy Here) response is routed back to 
the originating AS. 

9-10). The originating AS sends back a 183 (Session Progress) response to UE-A and initiates IVR procedures. User A 
is informed that CCBS is possible. User A activates CCBS. 

II -14). The originating AS subscribes for the call-completion event package. The terminating AS accepts the 
subscription and starts busy state supervision procedures on the callee. 

15-17). The terminating AS sends a notification to the originating AS. 

18-20). The originating AS sends Accounting Request[Event] to CDF, then the CDF creates an AS CDR for the CCBS 
service subscriber with CCBS indication on the AS CDR and returns Accounting Answer to the originating AS. 

21). After confirmation of the notification the originating AS starts announcements procedures informing about the 
activation of CCBS. 

22-23). The originating AS forwards the 486 (Busy Here) response to UE-A. 

24-27). When UE-B becomes available, the terminating AS sends a NOTIFY request to the originating AS, 

28-29). The originating AS starts the CCBS recall by sending an INVITE request to UE-B. In order to mark the 
INVITE request as a prioritized request for call-completion, the originating AS adds the "m" SIP URI parameter with 
the value 'BS' to the Request-URL 

5.2.2.1.13 CCNR Charging 

The following figure shows the Diameter transactions that are required between Application Server and CDF, which 
implements the CCNR service, and CDF after service execution. 
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UE-A 



Intermediate IM CN 
subsystem entities 



1. INVITE sipUE- 



10. 180 Ringing- 



0-AS 



-2. INVITE- 
-3. INVITE- 



CDF 



-4. INVITE- 



7. 180 Ringing 

Call- Info: <T-AS>; _ 

purpose=call- completiot? 

m=NR; 



8. 180 Ringing 
Call-lnfo:<T-AS>; 
purpose=call- completion 
m=NR; 



-9. 180Ringing- 



IVR: CCNR possible and activation 



11. SUBSCRIBE- 



12. SUBSCRIBE sipT-AS;m=NR 

From:<UE-A> 

To:<UE-B> - 

Contact<0-AS> 

Event call- completion 



1 3 . 202 Accepteel- 



14. 202 Accepted 



15. NOTIFY sipO-AS 
Event cal^ completion_ 
CO- state queued 
CO- service retentiotj 




18. Accounting 
Request[Event] 



T-AS 



UE-B 



-5. INVITE- 



-6. 180Ringing- 



19. Create an AS CD R 
indicating CCNR in it 



20. Accounting 
Answer 



21. 20001^ 

L 



user B activity 
supervision begins 



Figure 5.2.2.1.13-1 : Message Sequence Chart for Offline charging of CCNR service 

1-5). The communication is initiated by UE-A by sending an INVITE request. 

6). UE-B answers with a 180 (Ringing) response. The 180 (Ringing) response is routed back to the terminating AS. 

7-8). The terminating AS inserts a Call-Info header field in the 180 (Ringing) response. The Call-Info header field will 
contain the URI of the terminating AS with a "m" header field parameter set to "NR" (no reply). It further includes a 
"purpose" header field parameter set to "call-completion". The 180 (Ringing) response is routed back to the originating 
AS. 

9-10). The originating AS removes the Call-Info header field, forwards the 180 (Ringing) response to UE-A and 
initiates IVR procedures. User A is informed that CCNR is possible. User A activates CCNR. 
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1 1-14). The originating AS subscribes for the call-completion event package. The terminating AS accepts the 
subscription and starts activity supervision procedures on the callee. 

15-17). The terminating AS sends a notification to the originating AS,. 

18-20). The originating AS sends Accounting Request[Event] to CDF, then the CDF creates an AS CDR for the CCNR 
service subscriber with CCNR indication on the AS CDR and returns Accounting Answer to the originating AS. 

21). After confirmation of the notification the originating AS starts announcements procedures informing about the 
activation of CCNR. 

5.2.2.1 .14 Flexible Alerting (FA) 

5.2.2.1 .14.1 Flexible Alerting (FA) - establishment 

The following figure shows the Diameter transactions that are required between Application Server, implementing the 
FA service and CDF, with answer from one of FA group members. 
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UE-A 



S-CSCF 



1. INVITE (Pilot Ideitity) 



AS (FA) 



iFC 



1. INVITE (Pilot Id ;ntity) 



CDF 



2.UE-B and UE-C 
members of FA 
group "Pilot Identity" 



3. INVITE (UE-B) 



3. INVITE (UE-B) 



UE-B 



UE-C 



4 . SIP signalling : alerting phase between UE-A, S-CSCF, AS and UE-B 



5. INVITE (UE-C) 



5. INVITE (UE-C) 



6. SIP signalUng : alerting phase between AS (FA) S-CSCF and UE-C 



7.200 OK 



10..CANCEL 



10..CANCEL 



7.200 OC 



. Accounting Request 

> 



[Start/Event] 



Open/Create an AS 



9. Accounting Answer 



More SIP signalling 



UE-C answers 



Figure 5.2.2.1.14.1-1 : Message Sequence Chart for Offline charging of FA service - Answered 

UE-B and UE-C are FA group members of the FA group identified by the "Pilot Identity". 

A communication is requested from UE-A towards the "Pilot Identity". 

1) INVITE request incoming for "Pilot Identity". Based on the Initial Filter Criteria (IFC), indicating the request 
must be forwarded to an AS implementing FA for this "Pilot Identiry". 
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2) The AS implementing FA maps the Pilot Identity to the list of FA group members: UE-B and UE-C, and 
forwards INVITE to all FA members. 

3 to 4) INVITE forwarded towards UE-B and alerting phase signalling occurs with UE-A. 

5 to 6) INVITE forwarded towards UE-C and alerting phase signalling occurs with UE-A. 

7) UE-C answers. 

8 to 10) Upon reception of the 200 OK answer from UE-C, AS implementing the FA service: 

o Sends an Accounting-Request [Start] with FA MMTel supplementary service indication.The CDF 
creates an AS CDR and returns Accounting Answer to the AS. 

o Sends CANCEL to other FA group member being alerted, UE-B. 



5.2.2.1.14.2 



Flexible Alerting (FA) - call release 



The following figure shows the Diameter transactions that are required between Application Server, implementing the 
FA service and CDF, when previous successfully established call is released. 



UE-A 



1.BYE 



-«- 



S-CSCF 



200 OK 



l.BYE 



1.BYE 



200OK 



200 OK 



AS (FA) 



CDF 



2. Accounting Request [Stop] 



l.BYE 



Close the AS CDR 



3. Accounting An ;wer 



200 OK 



UE-C 



Figure 5.2.2.1.14.2-1 : Message Sequence Chart for Offline charging of FA service - Release 

1) UEC initiates release of the communication 

2 to 3) At session termination the AS implementing the FA service, sends an Accounting-Request [Stop] and the AS 
CDR is closed. 



5.2.2.1.15 



Malicious Communication Identification (MCID) 



The following figure shows the Diameter transactions that are required between Application Server implementing the 
MCID service and CDF for a successful MCID delivery for permanent mode or temporary mode. 
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Terminating UE-B Home Network 



S-CSCF 



1. INVITE 



AS 



iPC for B 



5. 200 OK 

< 



LINVITE 



CDF 



2. Temporary Storing 
data for MCID 



1. INVITE 



1. INVITE 



5. 200 OK 



5. 200 OK 



3. Accounting Request [Evsnt] 



UEB 



Create an AS CDR | 



4. Accounting Answer 



5. 200 OK 



6. SIP signalling 



7. re-INVITE 



7. re-INVITE 



8. Storing data 
for MCID 



9. Accounting Requ( st [Event/interim] 



Create/Update AS CDR 



10. Accounting Answer 



Figure 5.2.2.1.15-1 : Message Sequence Chart for Offline charging of IVICID service 

A communication is requested towards User B, and User B is subscribed to MCID service. 

1) INVITE request incoming for User B. Based on the Initial Filter Criteria (IPC) Rules, indicating that User B is 
subscribed to the MCID supplementary services, the communication is forwarded to an AS implementing 
MCID. 

2-4) In case of MCID temporary mode, AS stores relevant data temporarily, in case permanent mode AS registers 
the data and sends Accounting-Request [Event] to record invocation of MCID, acknowledged by the CDF when 
AS CDR is created.Then INVITE is forwarded to User B. 

5) 200 OK answer received from User B. 

6) Further SIP signalling for communication establishment, or mid-communication take place, before BYE from 

User-B. 
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7-10) Upon reception of re-INVITE from User-B, indicating temporary MCID request, AS registers the data 
previously stored and sends Accounting-Request [Event/interim] message to CDF to record invocation of 
MCID, the CDF creates/updates AS CDR and returns Accounting Answer. 

5.2.2.1.16 Customized Alerting Tone (CAT) 

Although CAT Supplementary services may be delivered according to different models (CAT forking, CAT early 
session, CAT Gateway) as described in TS 24.182 [217], only one scenario is depicted here, and serves as a basis for 
CAT charging description, as the same principle applies. 

The following figure shows the Diameter transactions that are required between Application Server implementing the 
CAT service and CDF for a successful communication establishment with CAT delivery. 
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Terminating UE-B Home Network 



UEA 



183 (session progress) 



S-CSCF 



1. INVITE 



AS 



iFC for B 



5. PRACK 



V.200 (PRACK) 

< 



LINVITE 



CDF 



2. Reserve CAT resources 



1. INVITE 



3. 180 Ringing 



4. 183 (session progress) 



5. PRACK 



1. INVITE 



3. 180 Ringing 



6. Start CAT media 



7.200 (PRACK) 



8.200 OK 



.200 OK 



9. Stop CAT media 



10. Accounting Request [Start/Event] 



UEB 



Open/Create an AS CDR 



11. Accounting Answer 



More SIP signalling 



Figure 5.2.2.1.16-1 : Message Sequence Chart for Offline charging of CAT service delivery 

A communication is requested towards User B, user B has subscribed to CAT service. 

1) INVITE request incoming for User B. Based on the Initial Filter Criteria (IFC) Rules, indicating that User B is 

subscribed to the CAT supplementary service, the communication is forwarded to an AS implementing CAT. 

2) The AS proceeds to CAT resources reservation and forwards INVITE towards User B.. 

3) 180 ringing is sent back from User B. 
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4) The AS sends a reliable 183 (session progress) response to User A with codecs to be used for CAT., 
acknowledged by PRACK from User A. 

5 to 7) Upon acknowledgment from User A (PRACK), the AS starts CAT media playing (alerting tone), and sends 
200 response to PRACK towards User A. 

• 8 to 1 1) Upon 200 OK answer received from User B, AS stops CAT media playing (alerting tone), 
and sends an Accounting-Request [Start/Event] message to CDF, CDF opens/creates an AS CDR 
and returns Accounting Answer. 

NOTE: The same following principle applies for all others CAT delivery scenarii : an Accounting-Request 

[START] is sent from AS to record beginning of alerting tone playing, and Accounting-Request [STOP] 
is sent to record end of alerting tone playing . 



5.2.2.1.17 



Closed User Group (CUG) 



5.2.2.1.17.1 



Closed User Group (CUG): Originating 



The following figure shows the Diameter transactions that are required between Application Server implementing the 
CUG service and CDF for a successful originating communication from User- A CUG member. 



Originating UE-A Home Network 



UEA 



S-CSCF 



1. INVITE (User B) 

► 



AS 



iFC for A 



1. INVITE 



CDF 



2. Check on request 
validity regarding CUG 



1 .INVITE (User B, CUG informatioi) 



1. INVITE (User B, CUG information) 



3. SIP signalling 



4. 200 OK 



4. 200 OK 



4. 200 OK 



4. 200 OK 



5. Accounting Request [Start/ Event] 



Open/Create AS CDR 



6. Accounting Answer 



Figure 5.2.2.1.17.1-1: Message Sequence Chart for Offline charging of CUG service- originating call 

User- A is subscribed to CUG service, and initiates a communication towards User B. 
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1) User-A initiates a communication towards User B sending INVITE request. Based on the Initial Filter Criteria 

(IFC) Rules, indicating that User A is subscribed to the CUG supplementary service, the communication is 
forwarded to an AS implementing CUG. 

2) AS performs checks from the request received regarding User A CUG subscription profile, and determines the 

CUG-communication is allowed for CUG member User-A towards User-B : AS forwards INVITE towards 
User-B with CUG information included. 

NOTE: In case the result from AS checks indicates non-CUG communication behaviour (for CUG 
communication with outgoing access...), CUG information is not included, and non-CUG 
communication charging applies. 

3) SIP signalling for communication establishment. 

4-6) 200 OK answer received from User B, and AS sends Accounting-Request [Start/Event] message to CDF to 
record start of the CUG-communication for User A CUG member. The CDF opens/creates an AS CDR and 
returns Accounting Answer. 



5.2.2.1.17.2 



Closed User Group (CUG): Terminating 



The following figure shows the Diameter transactions that are required between Application Server implementing the 
CUG service and CDF for a successful terminating communication towards User-B CUG member. 



Terminating UE-B Home Network 



S-CSCF 



AS 



CDF 



1. INVITE (User B, CUG Information) 



iFC for B 



1. INVITE (User B, CUG Information) 



2. Check on request 
validity regarding CUG 



1. INVITE 



UEB 



1. INVITE (User B) 



3. SIP signalling 



4. 200 OK 



4. 200 OK 

< 



4. 200 OK 



5. Accounting Request [i tart/Event] 



4. 200 OK 



Open/Create AS CDR 



6. Accounting Answer 



Figure 5.2.2.1.17.2-1 : Message Sequence Chart for Offline charging of CUG service - terminating call 

User-B is subscribed to CUG service. 
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1) incoming INVITE request towards User-B. Based on the Initial Filter Criteria (IFC) Rules, indicating that User B 

is subscribed to the CUG supplementary services, the communication is forwarded to an AS implementing CUG. 

2) AS performs checks from the request received regarding User B CUG subscription profile, and determines the 

CUG-communication is allowed for CUG member User-B from User A: AS forwards INVITE towards 
User-B. 

Note: In case the result from AS checks indicates non-CUG communication behaviour (incoming access from non- 
CUG member...), non-CUG communication charging applies. 

3) SIP signalling for communication establishment. 

4-6) 200 OK answer received from User B, and AS sends Accounting-Request [Start/Event] message to CDF to 
record start of the CUG-communication for User B CUG member. The CDF opens/creates an AS CDR and 
returns Accounting Answer. 

5.2.2.1.18 Personal Network Management 

The following figure shows the Diameter transactions that are required between Application Server implementing the 
"Personal Network Management" service and CDF for a successful "PN UE redirection" for a terminating 
communication, as described in TS 23.259 [218]. 
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1. INVITE UE-1 



S-CSCF-2 



iFC for UE- 1(B) 



5. 200 OK 



1. INVITE UE-1 



2. INVITE UE-2 



2. INVITE UE-2 



PNMAS 



CDF 



PNM redirection: active UE is UE-2 



3. iFC for UE-2(B) 



5. 200 OK 



2. INVITE UE-t 

► 



4. PNM redirection: active UE is 



2. INVITE UE-2 



5. 200 OK 



6. Accounting Request [Start/E\ 

► 



5. 200 OK 



More SIP signalling 



2. INVITE UE-2 



5. 200 OK 



ent] 



Open/Create an AS 



7. Ac counting Answer 



Figure 5.2.2.1.18-1 : Message Sequence Chart for Offline charging of "PNM-redirection" service. 

1) Incoming INVITE request for UE-1 of User B. Based on the Initial Filter Criteria (IFC) Rules, for UE-1, the 

communication is forwarded to the AS implementing PNM. From PN-user's PN configuration, the PNM AS 
determines the initial request is to be redirected to the default UE of the PN, i.e. to the UE-2. 

2) INVITE is forwarded towards UE-2. 

3) Based on the Initial Filter Criteria (IFC) Rules, for UE-2, the communication is forwarded to the AS 
implementing PNM. 

4) From PN-user's PN configuration, the PNM AS determines the initial request is to be sent to the default UE of 
the PN, i.e. to the UE-2. INVITE is forwarded towards UE-2. 

5) The destination UE-2 party answers and a final response is received. 
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5) Upon reception of the final response, the AS implementing the PNM service sends an Accounting-Request with 
Accounting-Record-Type indicating [START_RECORD/EVENT_RECORD] to record "PN UE redirection" 
execution to CDF. 

6) The CDF acknowledges the reception of the data and opens/creates an AS CDR. 



5.2.2.1.19 



Customized Ringing Signal (CRS) 



Although CRS Supplementary services may be delivered according to different models (download and play model, 
DTMF...) as described in TS 24.183 [219], only one scenario is depicted here, and serves as a basis for CRS charging 
description, as the same principle applies. 

The following figure shows the Diameter transactions that are required between Application Server implementing the 
CRS service and CDF for a successful communication establishment with CRS delivery. 
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Figure 5.2.2.1.19-1 : Message Sequence Chart for Offline charging of "CRS" service delivery. 
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A communication is requested towards User B, user B has subscribed to CRS service. 

1) INVITE request incoming for User B. Based on the Initial Filter Criteria (IFC) Rules, indicating that User B is 

subscribed to the CRS supplementary service, the communication is forwarded to an AS implementing CRS. The 
INVITE is forwarded towards User B. 

2) 180 ringing is sent back from User B. 

3 to 4) Upon acknowledgment from User A (PRACK), the AS reserves CRS media, and forwards PRACK towards 
UserB. 

5-6) Upon 200 OK(PRACK acknowledgment) from User B, the AS starts CRS media playing, and forwards 200 
OK towards User A. 

7-10) Upon 200 OK answer received from User B, the AS stops CRS media playing, and sends an Accounting- 
Request [Start/Event] message to CDF, CDF opens/creates an AS CDR and returns Accounting Answer. The AS 
forwards 200 OK towards User A. 

NOTE: The same following principle applies for all others CRS delivery scenarii: an Accounting-Request 
[Start/Event] is sent from AS to record CRS service delivery. 

5.2.2. 1 .20 Advice of Charge (AoC) 

The information flows showing the transactions between Application Server implementing the AoC service and CDF 
for AoC-S, AoC-D and AoC-E are described in TS 32.280 [21]. 

5.2.3 GTP' record transfer flows 

As in IMS offline charging, GTP' is not used between CDF and CGF for MMTel offline charging, because CDF and 
CGF are combined into CCF (see clause 4.2). 

NOTE: Vendors may nevertheless implement a separate CDF and CGF for MMTel offline charging. In this case, 
it is recommended that the approach chosen conforms to the principles and protocol applications specified 
in TS 32.295 [54]. 

5.2.4 B| CDR file transfer 

For further details on the Bj protocol application refer to 3GPP TS 32.297 [52]. 

5.3 MMTel online charging scenarios 
5.3.1 Basic principles 

Online charging of MMTel services is done according to the general principles of Diameter Credit-Control Applications 
(DCCA) as specified in TS 32.299 [50]. 

The CTFs implementing the MMTel online charging functionality may apply: 

• Immediate Event Charging (lEC) with CCR [event] generated, or 

• Event Charging with Unit Reservation (ECUR), or Session Charging with Unit Reservation (SCUR), 
both with CCR [Initial or Termination] generated. 

The circumstances on which lEC, ECUR or SCUR are applied, depend on the MMTel supplementary service and/or 
operator's policy. Further details are specified in clause 5.3.2. 
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5.3.2 Diameter message flows 



The flows described in the present document specify the charging communications between the different CTF entities 
and the charging functions for different onhne charging scenarios. The SIP messages and Diameter transactions 
associated with these online charging scenarios are shown primarily for general information and to illustrate the 
charging triggers. They are not intended to be exhaustive of all the SIP message flows discussed in TS 24.228 [200] and 
they depend on the Diameter Credit Control Request triggers configured by the operator. 

Each MMTel supplementary service is described by specific flows illustrating the dedicated trigger(s) for this MMTel 
supplementary service. 

Following message flows are defined in TS 32.260 [20], and can be re-used for charging the basic multimedia 
telephony capabilities: 

• Successful Session Establishment 

• Successful Session Establishment with Early Media Negotiation 

• Mid-Session Procedures 

• Session Release 

5.3.2.1 Message Flows - Successful Cases and Scenarios 

5.3.2.1 .0 Interaction with IMS-GWF 

As an MMTel principle, when Online Charging has to be applied for an MMTel supplementary service, and the trigger 
list includes IMS-GWF together with MMTel AS (implementing the MMTel supplementary service), filter criteria 
should be configured to have the MMTel AS triggered before IMS-GWF, in order to prevent improper charging. 

The following figure shows the Diameter transactions that are required between MMTel AS, IMS-GWF and OCS, 
when online charging is applied for MMTel supplementary service. 
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Originating UE-A Home 
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Figure 5.3.2.1 .0-1 : Message Sequence Chart for Online charging - IMS-GWF, MMTel AS and OCS 

1) User-A initiates a session by sending INVITE request. Based on the Initial Filter Criteria (IFC) Rules, indicating 
that User A is subscribed to the MMTel supplementary service X, the communication is forwarded to an AS 
implementing this service. 

2-3) As "online charging" is activated for User A, the AS sends a Credit-Control-Request (INITIAL_REQUEST, 
service X, ICID.) to the OCS for requesting units for the X supplementary service.The OCS grants units in the 
Credit-Control-Answer response for this request. The AS forwards INVITE via the S-CSCF. 

4) As "online charging" is activated for User A, IMS-GWF is triggered by the S-CSCF, and IMS-GWF sends a 
Credit-Control-Request (INITIAL_REQUEST, ICID.) to the OCS for requesting units for the session identified 
by ICID. 

5-6) The OCS detects this request is within a session for which there is already an ongoing online credit control 
Diameter session (same ICID). Based on operator policy the OCS can use either Credit_Control_not_applicable to 
supersede online charging in S-CSCF or grant appropriate service units (GSU). 



5.3.2.1.1 



Communications Diversion (CDIV) 



5.3.2.1.1.1 



Communications Diversion (CDIV) - successful establishment 



The following figure shows the Diameter transactions that are required between Application Server implementing the 
CDIV service and OCS, when online charging is applied to a successful CFU communication. 
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7. CCA (update, GSU) 



























Figure 5.3.2.1.1.1-1 : Message Sequence Chart for online charging of CDIV service - establishment 

A communication is requested towards User B: CFU and online-based charging activated for user B. 

1) INVITE request incoming for User B. Based on the iFC, indicating that User B is subscribed to the CDIV 

supplementary service, the communication is forwarded to AS implementing CDIV, where CFU is detected. 

2) As the subscriber is "online charging", the AS sends a Credit-Control-Request (INITIAL_REQUEST, service 
CDIV, ICID..) to the OCS for requesting units for the CDIV (CFU) supplementary service. 

3) The OCS grants units in the Credit-Control- Answer response for this request. 

4) The CDIV (CFU) can now be delivered: an Invite is sent towards user C via the S-CSCF. 

5-6) On answer from User-C (200 OK), the AS sends a Credit-Control-Request (UPDATE, USU) with possible 
already used units and requests new units to continue. 

7) New units are granted via Credit-Control- Answer and the 200 OK is propagated. 



5.3.2.1.1.2 



Communications Diversion (CDIV) - release 



The next figure shows the Diameter transactions occurring on release of the previous established communication, 
initiated by user C: 
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S- 



l.BYE 



4. 200 OK 



UE-B Home Network 



l.BYE 



l.BYE 



4. 200 OK 



4. 200 OK 



AS 



ors 



l.BYE (User C) 



2. CCR (terminate, service = CDIV, USU) 



End Credit Control 



3. CCA (terminate) 



4. 200 OK 



Figure 5.3.2.1.1.2-1 : Message Sequence Chart for Offline charging of CDIV service -release 

1) User C initiates release of the communication 

2) At session termination the AS implementing the CDIV service, sends a Credit-Control-Request 

(TERMINATION_REQUEST, used service units) for ending credit control. 



5.3.2.1.2 



Flexible Alerting (FA) 



The following figure shows the Diameter transactions that are required between Application Server implementing the 
FA service and OCS, when online charging is applied to a successful FA communication. 
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Figure 5.3.2.1.2-1 : Message Sequence Chart for Online charging of FA service 

UE-B and UE-C are FA group members of the FA group identified by the "Pilot Identity". 
A communication is requested from UE-A towards the "Pilot Identity". 

1) INVITE request incoming for "Pilot Identity". Based on the Initial Filter Criteria (IFC), indicating the request 

must be forwarded to an AS implementing FA for this "Pilot Identity". 

2) As "online charging" is activated for the "Pilot Identity", the AS implementing FA has to initiate parallel Invite 

towards each of FA group members. 
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3) For FA member User B, the AS sends a Credit-Control-Request (INITIAL_REQUEST, service FA, ICID-B) to 

the OCS for requesting units for the FA supplementary service. 

4) The OCS grants units in the Credit-Control-Answer response for this request. 

5) INVITE is sent towards User B via the S-CSCF. 

6) Alerting phase signalling occurs with UE-A. 

7) A parallel (from step 3 to step 6) scenario occurs towards User-C with session identified by ICID-C. 

8-9) Upon reception of the 200 OK answer from UE-C, AS sends CANCEL to other FA group member being 
alerted (UE-B). 

10) More signalling for CANCEL transactions 

11-13) When the last CANCEL transaction is terminated, AS sends a Credit-Control-Request (UPDATE, USU) with 
possible already used units, and requests new units to continue the communication between User A and User C. 

14) New units are granted via Credit-Control-Answer 

15) 200 OK is propagated towards User A. 

5.3.2.1.3 Closed User Group (CUG) 

5.3.2.1 .3.1 Closed User Group (CUG): Originating 

The following figure shows the Diameter transactions that are required between Application Server implementing the 
CUG service and OCS, when online charging is applied to a successful originating communication from User-A CUG 
member. 
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2. Check on request 
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6. 200 OK 
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7. CCR (update, USU) 



New Units requested 



8. CCA (update, GSU) 



SIP signalling 



Figure 5.3.2.1.3.1-1: Message Sequence Chart for Online charging of CUG service- originating call 

User- A is subscribed to CUG service, and initiates a communication towards User B. 

1) User-A initiates a communication towards User B sending INVITE request. Based on the Initial Filter Criteria 

(IFC) Rules, indicating that User A is subscribed to the CUG supplementary service, the communication is 
forwarded to an AS implementing CUG. 

2) AS performs checks from the request received regarding User A CUG subscription profile, and determines the 

CUG -communication is allowed for CUG member User-A towards User-B. 

3-4) As "online charging" is activated for User A, the AS sends a Credit-Control-Request (INITIAL_REQUEST, 
service CUG, ICID.) to the OCS for requesting units for the CUG supplementary service. The OCS grants units 
in the Credit-Control-Answer response for this request. The AS forwards INVITE via the S-CSCF towards User- 
B with CUG information included. 
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NOTE: In case the result from AS checks indicates non-CUG communication behaviour (for CUG communication 
with outgoing access...), non-CUG communication charging applies, and CUG information is not 
included in the forwarded Invite. 

5) SIP signalling for communication establishment. 

6-8) 200 OK answer received from User B, and AS sends a Credit-Control-Request (UPDATE, USU) with possible 
already used units, and requests new units to continue the CUG communication between User A and User B. 
New units are granted via Credit-Control- Answer, and 200 OK is propagated towards User A. 



5.3.2.1.3.2 



Closed User Group (CUG): Terminating 



The following figure shows the Diameter transactions that are required between Application Server implementing the 
CUG service and OCS, when online charging is applied to a successful terminating communication towards User-B 
CUG member. 

Terminating UE-B Home 
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ors 
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2. Check on request 
validity regarding CUG 
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Reserve units for incoming 
CUG for user B 



1. INVITE (User B) 



4. CCA (initial, GSU) 



1. INVITE (User B) 



5. SIP 



6. 200 OK 



6. 200 OK 



7. CCR (update, USU) 



New Units requested 



?. CCA (update, GSU) 



6. 200 OK 



SIP signalling 



Figure 5.3.2.1 .3.2-1 : Message Sequence Chart for Online charging of CUG service - terminating call 

User-B is subscribed to CUG service. 
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1) Incoming INVITE request with CUG information towards User-B. Based on the Initial Filter Criteria (IFC) Rules, 

indicating that User B is subscribed to the CUG supplementary services, the communication is forwarded to an 
AS implementing CUG. 

2) AS performs checks from the request received regarding User B CUG subscription profile, and determines the 

CUG-communication is allowed for CUG member User-B from User A. 

3-4) As "online charging" is activated for User B, the AS sends a Credit-Control-Request (INITIAL_REQUEST, 
service CUG, ICID.) to the OCS for requesting units for the CUG supplementary service. The OCS grants units 
in the Credit-Control-Answer response for this request. The AS forwards INVITE via the S-CSCF towards User- 
B. 

NOTE: In case the result from AS checks indicates non-CUG communication behaviour (incoming access from 
non-CUG member...), non-CUG communication charging applies. 

5) SIP signalling for communication establishment. 

6-8) 200 OK answer received from User B, and AS sends a Credit-Control-Request (UPDATE, USU) with possible 
already used units, and requests new units to continue the CUG communication between User B and User A. 
New units are granted via Credit-Control- Answer, and 200 OK is propagated towards User A. 

5.3.2.1 .4 Conference (CONF) 

The following figures show the Diameter transactions that are required between Application Server implementing the 
CONF service and OCS, when online charging is applied to different conference scenarios. 

For CONF service, two different set of scenarios are provided for illustrating the situation where ECUR or SCUR 
apply, depending on operator's policy. 



£75/ 



3GPP TS 32.275 version 11.2.1 Release 11 



68 



ETSI TS 132 275 V1 1.2.1 (2013-04) 



5.3.2.1.4.1 



CONF - user creating a conference - ECUR mode 



Originating UE-A Home Network 



UEA 



S-CSCF 



1. INVITE (conference factory URI) 



AS 



iFC for A 



1. INVITE 



ocs 



2. Allocate Conference resource 



3. CCR (initial, service = CONF, RSU) 
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CONF creation 



4. CCA (initial, GSU) 



5. Media resource negociation process. 



6. 200 OK 



7. ACK 



6. 200 OK 



7. ACK 



8. CCR (terminate, USU) 



End credit control 



9. CCA (terminate) 



Figure 5.3.2.1.4.1-1 : Message Sequence Chart for Online charging of CONF service- User creating a 

conference - ECUR mode 

1). User-A initiates a conference by sending an INVITE request to S-CSCF. Based on the Initial Filter Criteria (IFC) 
Rules, indicating that User A is subscribed to the CONF supplementary service, the communication is forwarded 
to an AS implementing CONF. 

2). The CONF AS allocates the conference resource. 

3-4) As "online charging" is activated, the AS sends a Credit-Control-Request (INITIAL_REQUEST, service 
CONF, creation) to the OCS for requesting units for the CONF supplementary service creation.The OCS grants 
units in the Credit-Control-Answer response for this request. 

5) Media resource negociation process. 

6-7) The AS (CONF) sends a 200 OK response replied by ACK from UE-A. 

8-9) On successful service deUvery, AS (CONF) sends Credit-Control-Request (TERMINATION_REQUEST, 
USU) for ending credit control, with granted units used for CONF creation. 
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5.3.2.1.4.2 



CONF - user creating a conference - SCUR mode 
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9. CCA (update, GSU) 



Figure 5.3.2.1.4.2-1 : Message Sequence Chart for Online charging of CONF service- User creating a 

conference - SCUR mode 

1). User-A initiates a conference by sending an INVITE request to S-CSCF. Based on the Initial Filter Criteria (IFC) 
Rules, indicating that User A is subscribed to the CONF supplementary service, the communication is forwarded 
to an AS implementing CONF. 

2). The CONF AS allocates the conference resource. 

3-4) As "online charging" is activated, the AS sends a Credit-Control-Request (INITIAL_REQUEST, service 
CONF, creation) to the OCS for requesting units for the CONF supplementary service creation.The OCS grants 
units in the Credit-Control-Answer response for this request. 

5) Media resource negociation process. 

6-7) The AS (CONF) sends a 200 OK response replied by ACK from UE-A. 

8-9) As CONF charging is based on duration or other CONF parameters, from start of the service on step 7), new 
units are subsequently requested by sending Credit-Control-Request (UPDATE, USU) with already used units, 
for continuing the service when new CONF parameters or values are provided. 
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5.3.2.1.4.3 



CONF - user joining a conference (SCUR mode) 
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Figure 5.3.2.1 .4.3-1 : Message Sequence Chart for Online charging of CONF service- User joining a 

conference - SCUR mode 

1) The conference has already been created by User A. User-B sends an INVITE request to S-CSCF in order to join 

in the conference identified by the conference URL The communication is forwarded to AS addressed by 
conference URL 

2) Media resource negociation process for adding UE-B to the conference. 

3-4) The AS (CONF) sends a 200 OK response replied by ACK from UE-B. 

5-6) This step applies for SCUR mode, when "Nb of participants" is needed for the "online charging" running for 
this conference: the AS(CONF) sends a Credit-Control-Request (UPDATE, USU) with possible already used 
units, for requesting new units with new number of participants. The OCS grants units in the Credit-Control- 
Answer response for this request. 
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5.3.2.1.4.4 



CONF - user inviting another user to a conference (SCUR mode) 
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Figure 5.3.2.1.4.4-1 : Message Sequence Chart for Online charging of CONF service- User inviting 

another user to a conference - SCUR mode 



1) The conference has already been created by User A. User A sends a REFER request to S-CSCF with the 
conference URI in order to invite User B into the conference. The communication is forwarded to the AS 
addressed by conference URL 

2-4) Sequence between UE-A and AS (CONF) to proceed the REFER (accept, NOTIFY...). 

5) User B is invited to the Conference by INVITE from AS (CONF). 

6) Media resource negociation process for adding UE-B to the conference. 

7-8) UE-B sends 200 OK response when he joins the conf, replied by ACK from AS (CONF). 
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9-10) This step applies for SCUR mode, when "Nb of participants" is needed for the "online charging" running for 
this conference: the AS(CONF) sends a Credit-Control-Request (UPDATE, USU) with possible already used 
units, for requesting new units with new number of participants. The OCS grants units in the Credit-Control- 
Answer response for this request. 



5.3.2.1.4.5 



CONF - user leaving a conference (SCUR mode) 
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Figure 5.3.2.1.4.5-1 : Message Sequence Chart for Online chiarging of CONF service- User leaving a 

conference SCUR mode 



1) The conference has already been created. User B sends a BYE request request to the AS (CONF) in order to quit the 
conference.The communication is forwarded to the AS addressed by conference URI. 

2-3) This step applies for SCUR mode: 

In case "Nb of participants" is needed for the "online charging" running for this conference, and UE-B 
leaving does not cause conference termination: the AS(CONF) sends a Credit-Control-Request (UPDATE, 
USU) with possible already used units, for requesting new units with new number of participants. The 
OCS grants units in the Credit-Control- Answer response for this request. 

In case UE-B leaving does cause conference termination, the AS(CONF) sends a Credit-Control-Request 
(TERMINATION_REQUEST, USU) with used units, for ending credit control. 
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4) The AS (CONF) sends back SIP 200 ok response to UE-B. 

5-6) The AS (CONF) sends a NOTIFY request to UE-B for unsubscribe UE-B to conf event package, replied by 200 
OK from UE-B. 

7) This step does not apply if conference has terminated: Other conference participants are Notified UE-B has quit the 
conference. 

5.3.2.1 .4.6 CONF (3PTY) - successful establishment 

The following figures show the Diameter transactions that are required between Application Server implementing the 
CONF (3PTY) service and OCS, when online charging is applied to a successful 3PTY conference scenario. 
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Figure 5.3.2.1.4.6-1 : Message Sequence Chart for online charging of CONF (3PTY) service ' 

establishment 
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1) UE-A and UE-B have established communication. UE-A puts UE-B on hold. Before invoking the 3-Way Calling 

UE-A establishes a communication with UE-C. 

2) UE-A sends an INVITE request to the AS (CONE) to establish a 3PTY session. 

3-4) As "online charging" is activated, the AS (CONE) sends a Credit-Control-Request (INITIAL_REQUEST, 
service CONE (3PTY)) to the OCS for requesting units for the service. The OCS grants units in the Credit- 
Control-Answer response for this request. 

5-6) The AS (CONE) sends a 200 OK response rephed by ACK from UE-A. 

7) UE-A sends a REEER request to UE-B with the Refer-To header set to the address of the AS (CONE). 

8) Sequence for 3PTY establishment: 

• REFER sequence (accept, NOTIEY...) between UE-B and UE-A. 

• INVITE from UE-B sequence for joining 

• Original communication UE-A UE-B sequence termination 

• REFER sequence (accept, NOTIFY...) between UE-A and UE-C. 

9-11) INVITE from UE-C sequence for joining the CONE (3PTY) 

12-13) In case ECUR mode applies to CONE (3PTY) Charging, on ACK receipt , AS (CONE) sends Credit- 
Control-Request (TERMINATION_REQUEST, USU) for ending credit control, with granted units used for 
3PTYcreation. 

In case SCUR mode applies to CONE (3PTY) Charging (charging to be based on duration or other 
parameters), from ACK receipt, new units are subsequently requested by sending Credit-Control-Request 
(UPDATE, USU) with already used units, for continuing the service when new CONE parameters or values have 
are provided. 

14) Original communication UE-A UE-C sequence termination, occuring at any time from step 11. 



5.3.2.1 .5 Explicit Communication Transfer (ECT) 

The following figure shows the Diameter transactions that are required between Application Server implementing the 
ECT service and OCS, when online charging is applied to a successful Blind Transfert from User A to User C, initiated 
by User B. 

For diagram simplification, only one OCS is shown. 

5.3.2.1 .5.1 Explicit Communication Transfer (ECT): Blind Transfer with sending REFER 
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6. More signalling between (A, x-CSCF, AS-A) and (x-CSCF, AS-B, B) for previous A-B media termination 



Figure 5.3.2.1.5.1-1 : Message Sequence Chart for online charging of ECT service establishment - 

Blind Transfer (part 1) 
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17. More signalling between (A, x-CSCF, AS-A) and (x-CSCF, AS-B, B) 



Figure 5.3.2.1.5.1-2: Message Sequence Chart for online charging of ECT service establishment 

Blind Transfer (part 2) 

In this scenario User A is the transferee. User B is the transferor, and User C is the transfer target. 
User A and User B are in an established communication. User B puts User A on Hold. 
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1) User B sends REFER request in the existing A-B dialog, to initiate transfer User A to User C. Based on the iFC, 
indicating that User B is subscribed to the ECT supplementary service, the communication is forwarded to AS 
implementing ECT. 

2-3) As "online charging" is activated, the AS sends a Credit-Control-Request (INITIAL_REQUEST, service ECT) 
to the OCS for requesting units for the ECT supplementary service. The OCS grants units in the Credit-Control- 
Answer response for this request. The AS generates an "ECT Session Identifier" replacing User C as the new 
destination information and forwards REFER towards User A. 

4-5) As "online charging" is activated for User A, the AS sends a Credit-Control-Request (INITIAL_REQUEST, 
service ECT) to the OCS for requesting units for the ECT supplementary service for the transferee. The OCS 
grants units in the Credit-Control-Answer response for this request. The AS forwards REFER towards User-A. 

6) More signalling between (User A, x-CSCF, AS-A) and (x-CSCF, AS-B, User B) for REFER acceptation 

sequence and terminating previous media between User A and User B. 

7) User A initiates a new session by sending an INVITE request with "ECT Session Identifier". 

8-9) AS implementing the ECT service for the transferee correlates this INVITE to the transfer being processed, and 
new units are requested by sending Credit-Control-Request (UPDATE, USU) with already used units, for 
continuing the service. The AS forwards INVITE request. 

10-11) AS implementing the ECT service for the transferor correlates this INVITE to the initial session to be 

transferred and new units are requested by sending Credit-Control-Request (UPDATE, USU) with already used 
units, for continuing the service, prior to forwarding INVITE towards UE-C. 

12) The destination User C party answers, and a final response is received. 

13-14) On transfer execution, the AS sends a Credit-Control-Request (UPDATE, USU) with possible already used 
units and requests new units for transferor to continue. 

15-16) On transfer execution, the AS sends a Credit-Control-Request (UPDATE, USU) with possible already used 
units and requests new units for transferee to continue. 

NOTE: For "Consultative Transfer" scenario, the same steps apply for interactions with OCS for transferee and 

transferor: Credit-Control-Request (INITIAL_REQUEST ...) on REFER initiating, intermediate Credit- 
Control-Request (UPDATE...) for more units on INVITE for new session, and Credit-Control-Request 
(UPDATE...) for more units on transfer execution when User C answers. 
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5.3.2.1.5.2 



Explicit Communication Transfer (ECT): Blind Transfer with 3PCC 



S-CSCF A 



ASA 



S-CSCF B 



ASB 



OCS 



A and B established communication - B puts A on Hold 



9. RE-INVITE 

^0. 200 OK 

► 



13. ACK 



9. RE-INVITE 



10. 200 OK 



13. ACK 



1. REFER (user -C) 



iPC 



1. REFER (User C) 



2. CCR (initial, service = ECT, RSU) 



Reserve Units for ECT for B 



3. CCA (initial, GSU) 



4. More signaling between AS-B, x-CSCF, 
and B for REFER handling 



5. INVITE (use r-C) 
' 57 INVITE (user-C) 



5. Provisional resp. 18 



6. Provisional resp. 18x 



9. RE-INVITE 



10. 200 OK 



13. ACK 



7. CCR (update, USU) 



New Units requested 



8. CCA (update, GSU) 



11. CCR (update, USU) 



New Units requested 



12. CCA (update, GSU) 



More signaling between AS-B, x-CSCF, 
and User C 



14. 200 OK 



14. 200 OK 



15. CCR (update, USU) 



New Units requested 



16. CCA (update, GSU) 
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Figure 5.3.2.1 .5.2-1 : Message Sequence Chart for online charging of ECT service establishment - 

Blind Transfer with 3PCC 

In this scenario User A is the transferee, User B is the transferor, and User C is the transfer target, and the User B's AS 
acts as a 3PCC (Third Party Call Control) initiating B2BUA: 

User A and User B are in an established communication. User B puts User A on Hold. 

1) User B sends REFER request in the existing A-B dialog, to initiate transfer User A to User C. Based on the iPC, 
indicating that User B is subscribed to the ECT supplementary service, the communication is forwarded to AS 
implementing ECT in a 3PCC mode. 

2-3) As "online charging" is activated, the AS sends a Credit-Control-Request (INITIAL_REQUEST, service ECT) 
to the OCS for requesting units for the ECT supplementary service. The OCS grants units in the Credit-Control- 
Answer response for this request. 

4-5) AS B performs the REFER procedure with User B, and sends INVITE towards User C. 

6-8) On Provisionnal response from User C, the AS sends a Credit-Control-Request (UPDATE, USU) with possible 
already used units and requests new units for transferor to continue. 

9) AS B sends Re-INVITE towards User A on existing dialog. From User A side, the basic Re-INVITE procedure 
applies (ECT service not invoked). 

10-13) On 200 OK response from User A, the AS sends a Credit-Control-Request (UPDATE, USU) with possible 
already used units and requests new units for transferor to continue, and sends ACK back to User A. 

14-16) On 200 OK response from User C, the AS sends a Credit-Control-Request (UPDATE, USU) with possible 
already used units and requests new units for transferred communication to continue. 

5.3.2.1 .5.3 Explicit Communication Transfer (ECT): Release 

The following figure shows the Diameter transactions that are required between Application Servers implementing the 
ECT service for the transferor and for the transferee, and OCS: release from User A, after a successful Blind Transfer 
from User A to User C, initiated by User B. 
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ASB 
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End Credit Control for A 
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l.BYE 












End Credit Control for B 












5. CCA (terminate) 










l.BYE 
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6.] 


VIore signalling beti 


>veen (A, x-CSCF, AS-A) and (x-CSCF, AS-B, B) for termination 













































Figure 5.3.2.1.5.3-1 : Message Sequence Chart for Offline charging of ECT service - Release 



1) User A initiates release of the communication 

2-3) At session termination the AS implementing the ECT service for the transferee, sends a Credit-Control-Request 
(TERMINATION_REQUEST, USU) with used units, for ending credit control. 

4-5) At session termination the AS implementing the ECT service for the transferor, sends a Credit-Control-Request 
(TERMINATION_REQUEST, USU) with used units, for ending credit control. 

NOTE: For "Blind Transfer with 3PCC" release scenario, only interactions between AS-B and OCS apply for ECT 

service. 
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5.2.2.2 Message Flows - Error Cases and Scenarios 

Error cases and Scenarios for SIP related procedures and Diameter related procedures used for MMTel Service and 
Supplementary Services Charging are defined in TS 32.260 [20]. 
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6 Definition of charging information 

6.1 Data description for MMTel offline charging 
6.1 .1 Rf message contents 

For offline charging, the different service CTFs supporting MMtel specific service charging generate accounting 
information transferred to the CDF using the Diameter accounting appHcation, as described in the TS 32.299 [50]. 

The Charging Data Request and Charging Data Response are used for this MMTel service offline charging, as 
described in TS 32.260 [20]. 

6.1 .1 .1 Charging Data-Request Message Description 

The generic Charging Data-Request message described in TS 32.260[20] used for MMTel offline charging is enhanced 
with specific MMTel service information. 

The following table illustrates the overall Charging Data-Request message as used for MMTel offline charging. 
Table 6.1.1.1 : Charging Data Request Message Contents 



Field [Category | ^»^ Description 



See Charging Data-Request message fields described in TS 32.260 [20] 



Service Information Om This field holds tlie MMTel specific parameter and is described in clause 6.3. 



NOTE: Detailed descriptions of the fields are provided in 3GPP TS 32.299 [50] . 

6.1 .1 .2 Charging Data Response Message Description 

The generic Charging Data-Responset message described in TS 32.260[20] is used for MMTel offline charging. 

6.1 .2 GTP' message contents 

Not applicable. Refer to subclause 5.2.3 for further information. 

6.1 .3 CDR Description on the Bi Interface 
6.1.3.1 CDR Field Type 

The MMTel CDR content and format description is based on TS 32.260[20] AS-CDR description, enhanced with 
specific MMTel service information. 

The content of MMTel CDR type is defined in the table in clause 6.1.3.3. The field definition includes the field name, 
category and description. The detailed field descriptions are provided in TS 32.298 [51]. 

The CDF provides the CDRs at the Bi interface in the format and encoding described in TS 32.298 [51]. Additional 
CDR formats and contents may be available at the interface to the billing system to meet the requirements of the billing 
system, these are outside of the scope of 3GPP standardisation. 
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6.1.3.2 



CDR Triggers 



Accounting information for MMTel services charging is transferred from the CTFs supporting MMtel service charging 
to the CDF, using Charging Data Request Start, Interim Stop or Event messages, depending on MMTel service 
behaviour (detailed in clause 5.2.2). Within the CDF, the CDRs triggering follows the same principle as described for 
SIP sessions in TS 32.260[20] : MMTel CDR is opened upon reception of a Charging Data Request [Start] message, 
closed upon reception of a Charging Data Request [Stop] message, updated upon reception of a Charging Data Request 
[Interim], and created upon reception of a Charging Data Request [Event]. 



6.1.3.3 



MMTel- AS CDR Content 



The MMTel CDR content and format description is based on TS 32.260[20] AS-CDR description, enhanced with 
specific MMTel information. 

The detailed description of the field is provided in TS 32.298 [51]. 

Table 6.1.3.3: Charging Data of MMTel CDR 



Field 



[Category 



Description 



See Charging Data of AS CDR described in TS 32.260 [20]. 



IVIIVITel information 



Oc 



This field includes a list of IVIMTel supplementary services which may occur within 
the same AS. 

The IVIMTel supplementary services related informations are described in Clause 
6.3.1.2. 



6.2 Data description for IVIIVITel online charging 
6.2.1 Ro message contents 

For online charging, the different service CTFs supporting MMTel specific service charging, generate debit and reserve 
units information transferred to the OCF. For this purpose, MMTel online charging utilises the Debit Units and Reserve 
Units procedure specified in the Debit / Reserve Units operation in TS 32.299 [50]. 

The Debit /Reserve Units Request and Debit /Reserve Units Response messages are used for this MMTel service 
online charging, as described in TS 32.260 [20]. 



6.2.1.1 



Debit and Reserve Units Request Message 



The generic Debit / Reserve Units Request message described in TS 32.260[20], used for MMTel online charging is 
enhanced with specific MMTel service information. 

The following table illustrates the overall Debit /Reserve Units Request message as used for MMTel online charging 
Table 6.2.1.1 : Debit and Reserve units Request Message Contents 



Field 


Category Description 


N0TE1 


Multiple Unit Operation 


Oc 


This field contains all parameters for the quota management. 


Service Identifier 


Oc 


This field contains identity of MMTel service. It holds the "Service Type" 
parameter (described in table 6.3.1 .2 ) value. 


NOTE 1 


Service Information 


Om 


This field holds the MMTel specific parameter and is described in clause 6.3. 









NOTE 1: See Debit /Reserve Units Request message fields described in TS 32.260 [20]. 
NOTE 2: Detailed descriptions of the fields are provided in TS 32.299 [50]. 
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6.2.1 .2 Debit and Reserve Units Response IVIessage 

The generic Debit / Reserve Units Response message described in TS 32.260[20] is used for MMTel online charging. 

6.3 MMTel Charging Specific Parameters 
6.3.1 Definition of IVIIVITel charging information 

The MMTel Information parameter used for MMTel charging is provided in the Service Information parameter. 

6.3.1 .1 MMTel charging information assignment for Service Information 

The components in the Service Information that are use for MMTel charging can be found in Table 6.3.1.1. 
Table 6.3.1.1 : Service Information used for MMTel Charging 



Field 


Category 


Description 


Service Information 


Om 


A set of fields hold the 3GPP specific parameter as 
defined in 3GPP TS 32.299 [50]. 


Subscription Id 


Om 


Used as defined in 3GPP TS 32.260 [20]. 


IIVIS Information 


Oc 


The details are defined in 3GPP TS 32.260 [20]. 


IVIIVITel Information 


Om 


This field holds a set of IVIMTel services with theirs 
specific parameters. The details are defined in 
clause 6.3.1.2. 



6.3.1.2 



Definition of the MMTel Information 



MMTel specific charging information is provided within the MMTel Information, and the detailed structure of the 
MMTel Information can be found in table 6.3.1.2. 
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Table 6.3.1.2: Structure of the MMTel Information 



Field 


Category Description | 


Supplementary Service 


Om 


This is a grouped field comprising several sub-fields associated with one 
supplementary service. It can be present multiple times as necessary to 
present the parallel activity of the different supplementary services. 


Service Type 


Om 


This field holds the type of the Supplementary Service, i.e. OIP, OIR, TIP, 
TIR, CW, HOLD, CB, MWI, CONF, CDIV, ECT, FA, MCID, CAT, CUG, 
PNM, CRS,AoC. 


Service IVIode 


Oc 


This field holds the mode of specific Service Type, i.e. for CB: ACR, ICB, 
OC, Bfor CDIV: CPU, CFB, CFNR, CFNRc, CFNL, CFUDB and for CONF: 
3PTY, AoC-S, AoC-D, AoC-E. 


Number of 
diversions 


Oc 


This field holds the number of diversions for CDIV. 


Associated party 
address 


Oc 


This field holds additional party identification needed for the service 
charging, i.e. for CDIV the "fonwarding party", for ECT the "transferor", for 
FA the "Pilot Identity", for 3PTY the "Initiator party". 


Service id 


Oc 


This field holds the conference ID for CONF supplementary service 


Change Time 


Oc 


This field holds the time of the requested action indicated in the "Participant 

Action Type" during the CONF supplementary service. It provides the time 

stamps for the CONF supplementary service parameters reporting. 

When the action is set to "CREATE", this field indicates the start time of the 

CONF supplementary service. 

When the action is set to "QUIT" and Number Of Participants holds the 

value "0", this field indicates the end time of the CONF supplementary 

service. 


Number Of 
Participants 


Oc 


This field holds the number of parties who are currently attached to the 
Conference at the time stamped indicated in the "Change Time", for the 
CONF supplementary service. 


Participant Action 
Type 


Oc 


This field holds the participant action type for CONF supplementary service 
(CREATE_CONF, JOIN_CONF, INVITE_CONF, QUIT_CONF) at the time 
stamped indicated in the "Change Time". 


CUG Information 


Oc 


This field holds the CUG information conveyed by the Network and 
identifies the CUG-communication : it is the "CUG Interlock Code" . 


AoC information 


Oc 


This field holds the AoC related Charging information conveyed to CDF, as 
defined in TS 32.280 [21]. 

Since AoC information may be sent more than once (e.g for AoC-S), this 
field may be multiple. 



6.3.1.3 



Support of MMTel Information in MMTel Offline Charging 



In table 6.3.1.3, the supported Operation Types for Service Type field within the MMTel Information on the Rf 
interface are presented. The other MMTel Information fields are not detailed. 

The supported Operation Types for Service Information fields, used in the Charging Data Request and Response 
messages for MMTel charging, other than MMTel Information fields, are described in TS 32.260 [20]. 

Operation Types for Service Type, encompasse the various situations, where the basic MMTel service Charging Data 
Request messages are sent from: 

a separate entity (another AS or S-CSCF), than the AS implementing the supplementary service, 
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the same AS. Each service may be reported through a dedicated Charging Data Request Message or combined Charging 
Data Request Messages (regrouped supplementary services or with basic MMTel service). 

Table 6.3.1.3: Supported values for Service Type in MMTel Information. 



Field 


Node Type 


AS 


Supported Operation Types 


S/l/S/E 






Service Type 




01 P (see note 1) 


SISE 


OIR 


SISE 


TIP 


SISE 


TIR (see note 2) 


SISE 


CW 


SISE 


HOLD (see note 3) 


SISE 


CB (see note 2) 


— E 


MWI 


— E 


CAT 


SISE 


CCBS 


SISE 


CCNR 


SISE 


CONF 


SISE 


CDIV 


SISE 


CDIVN 


SISE 


ECT 


SISE 


FA 


SISE 


MCID 


SISE 


CUG 


SISE 


PNM 


SISE 


CRS 


SISE 


AoC 


SISE 


NOTE 1 : Only present at terminating side. 

NOTE 2: Terminating side service. 

NOTE 3: AS may be involved for announcement purposes. 



6.3.1 .4 Support of MMTel Information in MMTel Online Charging 

In table 6.3.1.4 the basic structure of the supported fields within the MMTel Information in the Debit and Reserve Units 
Request for IMS online charging on the Ro interface are presented. The Operation types are listed in the following 
order: I (initial)/U (update)/T (terminate)/E (event). Therefore, when all Operation types are possible it is marked as 
lUTE. If only some Operation types are allowed for a node, only the appropriate letters are used (i.e. lUT or E) as 
indicated in the table heading. The omission of an Operation type for a particular field is marked with "-" (i.e. lU-E). 
Also, when an entire filed is not allowed in a node the entire cell is marked as "-". 

Table 6.3.1.4: Supported values in Debit and Reserve Units Request Message MMTel Information 



Field 


Node Type 


AS 


Supported Operation Types 


l/U/T/E 






Service Type 




OIP (see note 1) 


- 


OIR (see note 1) 


- 


TIP (see note 1) 


- 


TIR (see note 1) 


- 


CW (see note 1 ) 


- 


HOLD (see note 1) 


- 


CB (see note 1) 


- 


MWI (see note 1) 


- 


CAT (see note 1 ) 


- 


CCBS (see note 1) 


- 
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CCNR (see note 1) 


- 


CONF 


lUTE 


CDIV 


lUT- 


CDIVN 


— E 


ECT 


lUT- 


MOID (see note 1) 


- 


PNM (see note 1) 


- 


FA 


lUT- 


CUG 


lUT- 


CRS (see note 1) 


- 


AoC (see note 1) 


- 


NOTE 1 : Only reported in offline charging. 
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9.1.0 


Sep-2009 


SA-45 


SP-090538 


21 




Clarification on generic behaviour for Supplementary services 
Online Charging description 


C 


9.0.0 


9.1.0 


Dec 2009 


SA-46 


SP-090722 


22 




Add "Conference (CONF)" MMTel supplementary service Online 
Charging scenario 


B 


9.1.0 


9.2.0 


Dec 2009 


SA-46 


SP-090722 


23 




MMTel Online charging scenarios simplification - IMS-GWF 
interaction removal 


C 


9.1.0 


9.2.0 


Dec 2009 


SA-46 


SP-090722 


24 




Add "CONF (3PTY)" MMTel supplementary service Online 
Charging scenario 


B 


9.1.0 


9.2.0 


Dec 2009 


SA-46 


SP-090722 


25 




Add Messages description for MMTel Online Charging 


B 


9.1.0 


9.2.0 


Mar 2010 


SA-47 


SP-1 00044 


26 




Add "Explicit Communication Transfer (ECT)" MMTel 
supplementary service Online Charging scenario 


B 


9.2.0 


9.3.0 


Mar 2010 


SA-47 


SP-1 00040 


28 


. 


Correction on MMTel CDR description for Ealy SDP - Alignment 
with TS 32.260 


A 


9.2.0 


9.3.0 


Mar 2010 


SA-47 


SP-1 00040 


30 


. 


Correction in MMTel Charging for session priority - Alignment 
with TS 32.260 


A 


9.2.0 


9.3.0 


Mar 2010 


SA-47 


SP-1 00044 


31 




Add "Personal Network management" MMTel supplementary 
service charging description. 


B 


9.2.0 


9.3.0 


Mar 2010 


SA-47 


SP-1 00044 


32 




Add "Customized Ringing Signal (CRS)" MMTel supplementary 
service charging description 


B 


9.2.0 


9.3.0 


Mar 2010 


SA-47 


SP-1 00044 


33 




Add "Reverse Charging" MMTel supplementary service 
Charging not supported 


B 


9.2.0 


9.3.0 


Mar 2010 


SA-47 


SP-1 00044 


34 




Completion for Supported values setting for MMTel Information - 
Online Charging 


B 


9.2.0 


9.3.0 


Sep 2010 


SA-49 


SP-1 00496 


036 


.. 


Correction to Message Sequence Chart for Offline Charging of 
CW Service 


A 


9.3.0 


9.4.0 


Sep 2010 


SA-49 


SP-1 00497 


037 


.. 


Correction to Support of MMTel Information in MMTel Online 
Charging 


F 


9.3.0 


9.4.0 


Dec 2010 


SA-50 


SP-1 00758 


038 


2 


Correction of Communication session Barring (CB) to support 
MMTel Information in MMTel Offline Charging 


F 


9.4.0 


9.5.0 


Dec 2010 


SA-50 


SP-1 00758 


039 


2 


Correction of Communication Waiting (CW) Charging Flow 


F 


9.4.0 


9.5.0 


Mar 2011 


SA-51 


SP-1 101 09 


42 


1 


MMTel Charging enhancement for alignment with generic AS 
Charging description in TS 32.260 


C 


9.5.0 


10.0.0 


Mar 2011 


SA-51 


SP-110112 


40 


1 


Add 'Advice Of Charge (AoC)' MMTel supplementary service 
Charging description - Align with 22.173 


B 


9.5.0 


10.0.0 


Mar 2011 


SA-51 


SP-1 101 09 


41 


1 


Correction on Subscriber role 


F 


9.5.0 


10.0.0 
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2012-09 












Update 
to Rel- 
11 

version 
(MCC) 


10.0.0 


11.0.0 


2012-12 


SA-58 


SP-1 20793 


42 


1 


Single charging session applicability to MMTel 


B 


11.0.0 


11.1.0 


2013-03 


SA-59 








Changes from SA-59 implemented 




11.1.0 


11.2.0 


2013-04 










History table correction by MCC 




11.2.0 


11.2.1 
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